תוכן עניינים תכנון העבודה בפרויקט פתוח ד ר זאב בונן טופס הצטרפות לאיגוד מהנדסי המערכות INCOSE_IL

Transcription

1

2 תוכן עניינים קול המערכות - כתב העת של מהנדסי המערכות בישראל ע"מ 1 דבר העורך ד ר עמיהוד )עמי( הרי ע"מ 2 דבר מנכ ל אילטם משה סלם ע מ 3-4 דבר משפחת בונן שושנה בונן וגד בונן. ע מ 5 דבר נשיא INCOSE_IL חיים רייכמן ע"מ 6-17 תכנון העבודה בפרויקט פתוח ד ר זאב בונן ע"מ The New Taxonomy of Systems: Toward an Adaptive Systems Engineering Framework פרופ אהרון שנהר וד ר זאב בונן ע מ Issues in Man Made Systems Theory ד ר זאב בונן ע מ חידושים ואתגרים בהנדסת מערכות ד ר אביגדור זוננשיין ע מ 63 טופס הצטרפות לאיגוד מהנדסי המערכות INCOSE_IL

3 דבר העורך קורא יקר, הפעם מונח לפניך גיליון מיוחד, החלטנו להקדיש את הגיליון לשימור המורשת המקצועית של ד ר זאב בונן בהנדסת מערכות. זאב נפטר ב 2 במאי הוא היה מראשוני מניחי היסודות המקצועיים להנדסת מערכות בישראל. כוונתנו שגיליון זה ישמש בעתיד מהנדסי מערכות, משתלמים בהנדסת מערכות וסטודנטים להנדסת מערכות, לכן נכללו בו שלושה מאמרים, כולם פרי עטו של ד ר זאב בונן, המייצגים עשרות שנים של עשייה ויצירה בתחום הנדסת המערכות. המאמר הראשון, עקרונות תכנון פרויקט פיתוח, פורסם ברפאל בשנת במאמר זה פרסם זאב בונן לראשונה את סולם פערי הידע הידוע כיום כ סולם בונן ומשמש רבים בארץ ובעולם עד עצם היום הזה. אנו מודים להנהלת רפאל שנתנה את הסכמתה לפרסום המאמר בגיליון זה. המאמר השני, The New Taxonomy of Systems: Toward an Adaptive Systems Engineering Framework פורסם על ידי פרופ אהרון שנהר וד ר זאב בונן ב: IEEE Transactions On Systems, Man, And Cybernetics Part A: Systems And Humans, Vol. 27, No. 2, March 1997 המאמר מצביע על הצורך להתאים את תהליכי הנדסת המערכות של פרויקט לאי הוודאות הטכנולוגית ולרמת המורכבות של המערכת )מכלול, מערכת, מערך(. המאמר מציע דרכים להתמודדות עם היבטים שונים של הנדסת המערכות עבור פרויקטים שונים. אנו מודים ל IEEE על מתן האישור לפרסום המאמר בגיליון זה. המאמר השלישי,,Issues in Man Made Systems Theory מייצג את שנות עבודתו האחרונות בתחום הנדסת המערכות של זאב בונן. זאב הציע את המאמר לפרסום ב קול המערכות בעקבות הקורס שפיתח יחד עם תמיר בוסתנאי עבור תכנית הנדסת המערכות בטכניון. זאב לא הספיק לסיים את עריכת המאמר ואנו בחרנו לפרסם אותו בגיליון זה כ יצירה הבלתי גמורה שלו המייצגת את שנות פעילותו האחרונות בהנדסת מערכות. כמוכן תמצאו בעיתון כתבה אינפורמטיבית על הפעילויות בנושאי הנדסת מערכות שהתקיימו בארץ לאחרונה ביניהם הכנס על שם ד ר יוסי לוין שהתקיים בינואר בטכניון וכמובן רשמים מהכנס הדו שנתי של האיגוד הישראלי להנדסת מערכות שהתקיים במרץ לסיום, אני חוזר וקורא לכם, מהנדסי המערכות בישראל, לתרום מהידע והניסיון שצברתם ולשתף בו את קהיליית הנדסת המערכות שלנו. אנו מזמינים אתכם לכתוב מאמרים, תגובות או להעלות לדיון נושאים שיקבלו כאן במה. כמו כן נשמח לקבל מכם משוב ותגובות על החומר שמועלה בקול המערכות. כל דעה תתקבל בברכה. קריאה מהנה, ד ר עמיהוד )עמי( הרי, עורך העיתון 1

4 דבר מנכ ל אילטם שלום רב, בחצי שנה האחרונה ביצע אילטם פעילות ענפה שכללה כ 20 מפגשים טכנולוגיים, והבאה של חמישה מומחים בינלאומיים שהעבירו סדנאות באיגוד. בראשית חודש יולי יתקיימו שני אירועים מרכזיים בהשתתפות מומחים בינלאומיים חשובים. באירוע הראשון נארח את מר איליה יפה מומחה בינלאומי ל Signal Integrity ויו ר,IEEE Product Safety שיערוך סמינר בנושא שיקולי תכן מעגלים מודפסים בתדרים גבוהים מ - 2.GHz באירוע השני אורחת הכבוד הינה פרופ ננסי לבינסון, מאוניברסיטת,MIT מומחית בינלאומית בנושא בטיחות מערכות וחברה ב (NAE(.National Academy of Engineering פרופ ננסי תעביר סמינר בנושא Designing Safety into Complex Systems אשר יעסוק בתכן לבטיחות מערכות בשלבים הראשונים של הפיתוח. אנו מודים לננסי על הגעתה לארץ והעברת הסמינר. הסמינר נערך בשיתוף Incose_il ומוסד גורדון בטכניון. במהלך חודש יוני החלה את פעילותה ועדת היגוי משותפת לאילטם ול CS IEEE המרכזת והמנהלת של פעילות התוכנה והמחשוב של אילטם ושל CS.IEEE הועדה מורכבת מנציגי תעשייה ואקדמיה הבאים מ Computer Society, IEEE ומהחברות החברות באילטם. אנו מודים לחברי הועדה על הסכמתכם להתנדב למען הקהילייה התעשייתית של אנשי התוכנה והמחשוב. בהזדמנות זו ברצוני להודות לד ר לאה גולדין על הסכמתה לעמוד בראש הנהלה משותפת ולהוביל אותה. כמו כן תודה לגב שלומית מורד על שהובילה עד היום את תחום הנדסת התוכנה באילטם ועל נכונותה להמשיך ולתרום בריכוז תוכניות העבודה בעתיד. בחודש יוני נערך המפגש הראשון של קבוצת העבודה בנושא: שימוש חוזר בתוכנה, אותה מרכז ד ר עמיר תומר. קבוצת העבודה עוסקת בלימוד של מתודולוגיות לשימוש חוזר, שיטות למדידה, ניתוח כדאיות ושיתוף מידע וידע בין חברי הקבוצה מהחברות השונות. ברצוני להודות לרפי לוי, אשר פורש בספטמבר לגמלאות, עבור תרומתו לקהיליית תעשיית ההייטק בישראל ולאילטם. רפי, היית אבן בניין מרכזית בקביעת ערכי הניהול של האיגוד, שמירה על מיקוד הפעילות בצרכים העדכניים של התעשייה תוך הסתכלות רחבה על התרומה לטווח הארוך של פעילות האיגוד. מועמד להחליפו בנשיאות אילטם כנציג התע א הינו חיים רייכמן אשר מכהן כיום כנשיא.INCOSE_IL רפי, תודה על התרומה. לחיים, נאחל הרבה הצלחה בעבודה משותפת ופורייה. העיתון מוקדש הפעם לפעילותו ותרומתו של ד ר זאב בונן למיסוד הנדסת המערכות בתעשייה הישראלית. תודה לד ר עמי הרי, עורך העיתון, עבור נחישותו והשקעתו הרבה בהשגת והכנת החומר לגיליון זה. במהלך חצייה השני של שנת 2011 צפויים לנו למעלה מ 30 מפגשים טכנולוגיים אשר נועדו לשפר את התחרותיות של התעשייה עתירת הידע בישראל. הנכם מוזמנים לקחת חלק פעיל בפעילות השוטפת של האיגוד. אילטם הינה עמותה - מלכ ר ואינו בעל עניין מסחרי. באיגוד חברות כיום למעלה מ 100 חברות מהתעשייה האזרחים והביטחונית, החברות באילטם היא מוסדית כל עובדי החברה החברה באילטם זכאים להשתתף בפעילויות של האיגוד. נשמח לראותכם מצטרפים אלינו משה סלם מנכ"ל אילטם 2

5 דבר משפחת בונן שושנה בונן וגד בונן. ב מלאה שנה למותו של בעלי ז ל. לא, לא הפתעה ופלא היה בעיני שזאב הלך דוקא ללמד בטכניון ובפרט בתכנית להנדסת מערכות, וזאת אחרי קריירה מרשימה ברפא ל שבה עבד כל חייו והגיע לדרגת מנכ ל רפא ל, תפקיד שבו המשיך 13 שנה. זאב אהב ללמד. משנתו היתה ברורה לעצמו והוא חשב שחשוב להעביר אותה לדורות הבאים. ידע צריך להנחיל לבאים אחריך. זו נקודת מבט אחת. לא פחות חשובה היתה הפטריוטיות רחבת ההיקף שהיתה נחלתו של זאב. הוא לא הבין כיצד רבים מחבריו בוגרי טכניון, לוחמי מלחמת תש ח עזבו את מולדתם למנף קריירה בנכר ולהרוויח הרבה כסף. כל זה היה רחוק ממנו. אותו להט פטריוטי ציוני דחף אותו להקים את מפעל רפא ל בגליל. הוא הבין והפנים את משמעות יהוד הגליל כבר בשנות ה 80. בני הבכור גד בונן הסביר בכינוס השנתי של ה איגוד הישראלי להנדסת מערכות מדוע בחר אבא דווקא בהנדסת מערכות ודבריו מצורפים כאן: לכבוד רב הוא לי להיזכר באבא דווקא באכסניה מכובדת זו הכנס השנתי של האיגוד הישראלי להנדסת מערכות. הנדסת המערכות לא הייתה אהבת הנעורים של אבא הוא היה מהנדס אלקטרוניקה בהכשרתו ואיש ניהול במהלך הקריירה, אבל הוא בחר להתעמק בה דווקא מתוך בשלות מקצועית של אדם עתיר ניסיון ורב פעלים. אני מבין מה קסם לו היכולת לשלב בין תחומי ידע, היכולת לארגן את ההתמחויות ההנדסיות הצרות כך שביחד יצרו ערך, הצורך לפרק את הבעיות למרכיבים ולפתור כל מרכיב בכלים ייחודיים מבלי לאבד את התמונה הכוללת כל אלה היוו אתגר הולם ליכולות ולידע שהיו לו. הוא תמיד אהב לדבר על אינטר ועל מולטי דיסציפלינאריות, על,Systems of Systems בקיצור, המורכבות וחקר המורכבות הלהיבו אותו. ואכן, משהיו עיתותיו בידיו הוא בחר להעמיק בתחום, ולחלוק את הידע והתובנות שצבר עם הדורות הבאים של מהנדסים צעירים במסגרת קורס למוסמכים של התכנית להנדסת מערכות בטכניון. ומכאן הסיפוק הרב שמפעל זה, שהיה יקר ללבבו ממשיך להתקיים בהעדרו. כאן בדיוק המקום בשם בני המשפחה אמא שנאלצה להיעדר, אחי אורי שיושב בקהל ואנוכי, להודת מקרב לב לדר אבי גינצבורג: א. על שבחר להמשיך לשאת את הלפיד ולצקת תכנים חדשים לתוך המבנה שאבא הקים. ב. על שמצא את הדרך, בתוך המסגרת האקדמית, לציין את זכרו של האדם שהיה אבא. וכמובן ברכת הצלחה לקבוצת הסטודנטים שגילתה הצטיינות יתרה בפרויקט, ותציג את עבודתה במהלך מושב הבוקר. 3

6 קול המערכות - כתב העת של מהנדסי המערכות בישראל ד ר זאב בונן

7 דבר נשיא INCOSE- IL קוראים יקרים, בחודשים האחרונים היתה פעילות רבה מאוד באיגוד הישראלי להנדסת מערכות. שיא הפעילות היה כנס בין לאומי שהיה מוצלח ביותר. למעלה מ 400 מהנדסי מערכות מעשרות חברות שהשתתפו בכנס נחשפו לחידושים האחרונים, השתתפו בסמינרים שהועברו ע מומחים מחו ל ונחשפו לתערוכת כלים שהתקימה במסגרת הכנס. סיור מקצועי שנערך לאורחים מחו ל לאינטל קרית גת, אונברסיטת בן גוריון בבאר שבע, ומוזיאון חיל האוויר זכה לשבחים רבים מפי האורחים שנחשפו לחבל ארץ שונה מתל אביב, לתעשיה, לאקדמיה הישראלית וקצת להיסטוריה ולעוצמה של חייל האוויר הישראלי. המשובים שקיבלנו בכנס מראים על החשיבות שציבור המהנדסים מקנה לכנס כזה ולכלל פעילות האיגוד.INCOSE-IL בדיון הפקת לקחים שנערך אחרי הכנס כבר ניקבע יושב ראש לכנס הבא - מר עוזי אוריון, ניקבעה תוכנית פעולה ראשונית ולוח זמנים להתארגנות לקראת הכנס הבא ב אני קורא למי שרוצה לתרום לקידום הנדסת המערכות בארץ להתנדב ולהרתם לפעיליות השונות שמאורגנות ע י INCOSE-IL הן בקבוצות העבודה והן ביזום הרצאות ו/או ביצירת קשר עם מומחים בעלי שם בעולם. העיתון מוקדש הפעם לזכרו של זאב בונן ז ל שהיה מחלוצי הנדסת המערכות בארץ ופעל רבות לביסוס והגדרת הנדסת המערכות. זאב חינך דורות של מהנדסים, הוא פיתח שיטות וכלים הרבה לפני שהנושא צמח והוכר כמקצוע. גם כיום בקריאת מאמריו אנו רואים איזה חזון והבנה היו לזאב וכמה רלונטי גם היום לאמץ את דרכו. לאחרונה, נחשפנו למספר הצלחות בארץ במערכות חדשניות והטובות בעולם כגון כיפת ברזל, מעיל רוח, חץ 3 ועוד. לא ניתן להגיע להצלחות אלה ללא הנדסת מערכות מעולה. אין יכולת להגדיר חברה אחת אירגון כזה או אחר, קבוצת מהנדסים כזאת או אחרת שפיתחה כול אחת מהמערכות. כול מערכת מפותחת בשתוף פעולה של חברות רבות גדולות וקטנות ביטחוניות ואזרחיות כאחד. הדרך להנדסת מערכות מעולה הינה להגדיר, לישם וללמוד דרך שיתוף החלפת מידע בין המהנדסים השונים בין האירגונים והחברות, ללמוד מה קורה בעולם, ללמוד הצלחות, לנתח כישלונות ולרתום את האקדמיה להכשיר את דור מהנדסי המערכות הבא ולפתח מתודולוגיות חדשניות להנדסת מערכות. הפעילות שלINCOSE-IL בחסות אילטם, הגברת שיתוף הפעולה עם איגודים נוספים, אירגון ימי עיון, סמינרים, קבוצות עבודה ופעילויות עם מומחים מהארץ ומחו ל הינם הדרך להנדסת מערכות מעולה שתצעיד את כולנו קדימה ותאפשר למדינת ישראל לעמוד ביעדיה הביטחוניים והכלכליים. במסגרת הכנס נחשפנו לתוכנית הסמכה אישית להנדסת מערכות.CSEP תוכנית זאת הוגדרה ע י INCOSE ומקודמת על ידה. דר עמיר תומר במסגרת פעילתו ב INCOSE-IL הגדיר מפת דרכים לישום והטמעת נושא ההסמכה האישית בארץ. כולנו תקווה שפעילות זאת תמסד ותקדם את ההכרה במקצוע של מהנדס המערכות הנהלתINCOSE-IL החליטה לכוון את הפעילות להגברת השיתוף ושילוב בפעיליות השונות של חברות בינוניות וקטנות מהתחום האזרחי. החברות הביטחוניות הגדולות, בעלות אמצעים ומשאבים, רצות קדימה אבל ללא ישור קו עם החברות הבינוניות והקטנות יהיה קשה להמשיך לפתח ולהיות בחזית העולמית בפיתוח במערכות חדשניות מקוריות. הנכם מוזמנים לקחת חלק בפעיליות השוטפות של האיגוד, להכנס לאתר, להתעדכן ולהחשף לפעילויות ולחומר המפורסם. הרשמו ל INCOSE-IL אישית למרות היותכם חברים באילטם כעובדים בחברות החברות באילטם. רישום זה יאפשר הפצה ישירה אישית לכול אחד ואחד מכם על הפעיליות השוטפות. קריאה מהנה, חיים רייכמן נשיא INCOSE_IL 5

8 קול המערכות - כתב העת של מהנדסי המערכות בישראל המאמר הבא פורסם לראשונה כדוח פנימי של רפאל בפברואר אנו מודים לרפאל על האישור לפרסמו בגיליון זה. 1. כללי תכנון העבודה בפרויקט פתוח זאב בונן תכנון העבודה בפרויקט פתוח של מערכת מורכבת קשור בקשיים הנובעים מעצם מהותו של תהליך הפתוח. בפרויקטים בבנין ותעשיה למשל, בהם סדר הפעולות ידוע מראש, ניתן לתכנן את מהלך העבודה ע י תכנון רשת או שיטות דומות. מאידך בתהליך פתוח ישנם הרבה נעלמים שמתן התשובות להם, תוך כדי הפתוח משנה ומכתיב את המשך הפעילות. לפיכך יש המערערים )1( על האפשרות לתכנן את תהליך הפתוח ע י רשת פעולות מפורטת לטווח ארוך של כמה שנים מראש וטוענים שיש לתכנן את העבודה כתהליך החלטות עוקב הבנוי מעץ החלטות הנובעות מתוצאות המתקבלות במהלך הפתוח. לפי גרסא זו לא ניתן לתכנן קדימה לטווח זמן ארוך את מהלך הפתוח של מערכת מתקדמת. מאחר וספקטרום הפתוח כולל פעילויות שונות ומגוונות מאד הרי ששתי הגרסאות נכונות, כל אחת במקומה. מאידך, נראה להלן שאם לא ניתן לתכנן את מהלך פתוח המערכת שמדובר בה בצורה סבירה הרי פרוש הדבר שלא ניתן עדיין להגדיר את המערכת ע י מפרט פחות או יותר ידוע, )ולו גם עם מספר סימני שאלה(, המבוסס על אבני בנין שאף הן ידועות במידה סבירה. במקרה זה אנחנו עדיין נמצאים בשלב של פתוח טכניקות וטכנולוגיות, למוד מכלולים, בדיקת רעיון, תכנון מוקדם, קדם פרויקט וכו. בשלבים אלה אנו מחפשים את אותן התשובות שיאפשרו להגדיר מערכת מורכבת שתתן את הביצועים המבוקשים והנראית כניתנת לביצוע. הניסיון להריץ פרויקט בכל ההיקף בשלב זה מוליך בדרך כלל לכישלון ובזבוז עצום של אמצעים. כשלון הנובע במישרין מכך שהידע הטכני אינו בשל עדיין לפתוח המשולב של המערכת המורכבת בשלמותה. דבר זה מתבטא בצורה גרפית בהסתבכות תכנון פעולות הפתוח ובהופעת עץ החלטות מסועף שאת קצהו קשה לראות. חלק ניכר מדו ח זה כולל דברים ידועים ואולי אף נדושים, לא לשם השלמות, אלא שמתעלמים מהם לעתים לא רחוקות. מאידך, יש להודות שההכללות בדו ח נובעות מניסיון מעשי בתנאים מסוימים ובודאי אינן מדויקות בתנאים אחרים. בסעיף 2 של הדו ח נראה כיצד דרישות המפרט, פער הידע במכלולים השונים ובמערכת כולה וכן הצמודים ביניהם משפיעים על סיכון הפתוח; בסכום נגיע לכמה מסקנות כיצד להקטין את הסיכון. בסעיף 3 נטפל בתכנון העבודה ובהערכות זמנים ונציע כללים לתכנון העבודה לפי קריטריון של מינימום זמן. בסעיף 4 נעמוד על כמה מגבלות של תכנון לטווח ארוך. בסעיף 5 ניגע בקצרה בתכנון פתוח לפי קריטריון מינימום מחיר ועל הקושי בישומו בארץ. 6

9 2. תכנון מערכת מורכבת 2.1 גיבוש מפרט המערכת את תהליך התגבשות המפרט למערכת חדשה אפשר לתאר בציור מספר 1. מפרטי מכלולים מפרט מערכת טכני מפרט מבצעי מציאות מבצעית פער הידע תרגום תרגום דרישות ממכלולים מה ניתן להעשות השואה למפרט מבצעי השואה למציאות גיבוש מפרט מערכת ציור מספר 1 נציין שתי נקודות: 1 התפקיד. 1 המכריע של הדיאלוג ההדוק בין הצרכן לבין המפתח. בלעדיו לא ניתן להגיע ל ת ר ג ו ם האופטימאלי של הרצוי מחד אל המצוי היום והאפשרי מחר מאידך. אין המפתח צריך להסכים לתכתיבים מהסוג: זה מה שאנחנו רוצים, אנחנו יודעים למה אלו המטרות, סמוך עלינו אלה התנאים, ככה זה קורה אתה תעשה מה שאומרים לך וכו. עליו להבין היטב מהי המציאות המבצעית ומה הצרכן באמת צריך. רק בצורה כזו מגיעים ל תפירה הנכונה של המערכת לצורך. 2. התוצאה הסופית של גיבוש המפרט הנו פער הידע שיש לעבור בפתוח. פער גדול יותר עשוי להצביע על מערכת עם ביצועים מעולים יותר מהקיים היום )אם התכנון טוב(, אך גם על סיכון גבוה יותר בפתוח. נראה בהמשך כיצד נוכל לאמוד את מידת הסיכון. 7

10 קול המערכות - כתב העת של מהנדסי המערכות בישראל את הקשר בין מפרט המערכת למפרטי המכלולים נתאר בציור מספר 2. מפרט מערכת A D - A. B. C. D מפרטי מכלולים B C ידע במכלולים קשר בין מפרט המערכת למפרטי המכלולים ציור מספר 2 הקשרים בין מפרט המערכת למפרטי המכלולים ובין המכלולים לבין עצמם יכולים להיות דו-כיווניים או חד-כיווניים ולפעמים אין קשר ישיר בכלל. על החשיבות של אופי הקשרים לתכנון הכללי נעמוד מאוחר יותר. 2.2 על המכלול מהלך פתוח מכלול מהלך מכלול מתואר בציור מספר 3. 8

11 שנוי מפרט מערכת פתוח גמר מכניסים מכלול למערכה פתוח )תכנון, ביצוע, בדיקה( זמן פתוח בחירת פתרון קביעת מפרט מכלול מפרט מערכת הערכת זמן: נדרש עדכון זמן לא הספיק פתרון לא ניתן לביצוע מפרט מכלול לא ניתן לבצוע A1 A2 A3 מהלך פתוח מכלול ציור מספר 3 לאחר קביעת המפרט ובחירת פתרון באים תכנון, בצוע ובדיקות. כאשר מסתיימות הבדיקות ישנן כמה אפשרויות: הפתרון שנבחר עונה לדרישות. אין צורך בעדכונים. הפתרון שנבחר מתאים בכללותו אך יש צורך בעדכון )אחד או יותר( על מנת לקבל פתרון סופי.. 1 הפתרון אינו ניתן לביצוע. יש הכרח לבחור פתרון אחד ולחזור על הפתוח פרט המכלול אינו ניתן כלל לבצוע וכתוצאה מכך גם מפרט המערכת כולה עלול להתערער עם השלכות קטסטרופאליות על פתוחה. ברב המקרים יש יותר ממחזור פתוח אחד )2(, מספר המחזורים תלוי מאד בפער הידע שיש לגשר עליו בפתוח. על מנת להעריך את המספר הצפוי של מחזורי פתוח יש לאפיין את המכלול לפי קריטריון זה. 1. על עבודה על פתרונות במקביל ראה סעיף

12 קול המערכות - כתב העת של מהנדסי המערכות בישראל אפיון המכלול נוכל לחלק את המכלולים בהתאם ליחס שבין המפרט הנדרש לבין מידת הידע )או פער הידע( שלנו בטכנולוגיה שלו כדלקמן : 2 ידוע ועשוי ידוע על הנייר אך טרם נעשה אצלנו יש משפט קיום סיכון הולך וגדל אין משפט קיום 1. ידוע ועשוי מכלול מהטיפוס הנדרש כבר נעשה אצלנו בהצלחה. ההבדל במפרט הנוכחי לעומת העבר הנו בגדר שינויים הנדסיים סבירים ללא אכסטרפולציה גדולה לעומת התכנונים הקודמים. לדוגמא: פתוח מנוע מדלק מוצק רגיל בתחום מדות מוכר. במקרה זה הסיכון בפתוח קטן מאד. 2. ידוע על הניר אך טרם נעשה אצלנו מכלול שלגביו אפשר לקבל חלק ניכר או גדול מהידע הדרוש מהספרות, או אפילו את כולו ע י רישיון ידע. גם כאן הסיכון עדיין נמוך אך יש להטעים שתהליך הפיכת הידע הפוטנציאלי הנמצא על הניר בלבד, לידע מעשי, של מערכת בנויה ועובדת, עם פתרון כל הבעיות הקטנות שבדרך )גדולות אין לפי הגדרה( לוקח זמן ניכר. 3. יש משפט קיום ידוע שקיים בעולם מכלול בעל תכונות מסוימות רצויות אך אין אנו יודעים מהו הפתרון אפילו בקווים כלליים. דבר זה קורה לעיתים קרובות בפתוח בטחוני. אם הדבר חיוני עבורנו נוכל להניח שאם נשקיע מספיק מאמצים ומספיק זמן נגיע אף אנו לפתרון. 4. אין משפט קיום כאן הסיכון גבוה והרווח הצפוי לא תמיד ידוע. לעיתים קיימת נטייה להיכנס לפתוח מכלול כזה במסגרת פתוח מערכת מורכבת אם הרווח הצפוי גבוה מאד. נראה להלן שגישה זו מסוכנת מאד ליש להפריד פתוח מכלולים כאלה מפתוח מערכת שלמה ולהתייחס לכך כפתוח בסיסי של אבני בנין לטווח ארוך ) שלח לחמך על פני המים (. בסכום, פער הידע במכלול וסיכון הפתוח שלו גדלים ביחד. 2. במציאות יש גם מקרי ביניים. 10

13 2.2.3 סכום תכונות המכלול את הקשר בין פער הידע ובין מהלך הפיתוח של מכלול נוכל לסכם בטבלה מספר 1. טבלה מספר 1 תכונות מכלול סוג המכלול מהלך הפתוח מספר מחזורי פתוח n + 2? 1. ידוע ועשוי 2. ידוע על הנייר אך טרם נעשה אצלנו 3. יש משפט קיום 4. אין משפט קיום הפתרון שנבחר עונה. לרוב יש צורך בעדכון קטן. הפתרון שנבחר עונה בכללותו. לרוב נדרש עדכון גדול ואחריו עדכון קטן. לא תמיד בוחרים מיד בפתרון הנכון ולכן מופיעים 1 n מחזורים עבור פתרונות לא מוצלחים + 3 מחזורים עבור הפתרון הסופי. מנסים פתרונות שונים עד להצלחה או להודאה בכישלון והפסקה. לדוגמא מתואר בטבלה מספר 2 מהלך הפתוח של מכלולים מסוגים שונים עבור מערכת מורכבת מסוימת.)5( טבלה מספר 2 מהלך פתוח מכלולים למערכת מסוימת מס' אופי המכלול מס' מחזורים הערות מכנו-אופטי השתמשו במכלול קיים. הוכנסו הרבה שנויים קטנים באופן שוטף. - 1 אלקטרו- אופטי לא היה כל ידע מוקדם פרט למשפט קיום. בכל מחזור היה שינוי גדול לעומת קודמו. 3 2 אלקטרוני המכלול היה למעשה עדכון גדול של מכלול שפותח עבור מערכת קודמת )רעיון בסיס זהה( בנוסף לזאת הוכנסו שנויים קטנים רבים באופן שוטף. 1 3 מכני המחזור השני והשלישי כללו שנויים ניכרים לעומת התכנון המקורי. 3 4 חנ"ם עדכון קטן. מכלול ידוע. 1 5 רקטי עדכון קטן. מכלול ידוע. 1 6 מבנה עדכון קטן. מכלול ידוע

14 קול המערכות - כתב העת של מהנדסי המערכות בישראל 2.3 מסקנות לפתוח מכלולי המערכת בחירת מכלולים * * על מנת להקטין את סיכון פתוח המערכת ולאפשר בניית לוח זמנים ברור נראה כביכול שכדאי לבחור למערכת רק מכלולים מסוג 1. לפעמים אפשר אמנם לקבל ע י צרוף חדש של מכלולים ידועים מערכת חדשה, אולם לרוב נקבל מערכת מיושנת, כלומר מערכת שלא כדאי לפתח אותה! על מנת להשיג מערכת יותר טובה מהקיים הכרחי להסתכן ולבחור מכלולים פחות ידועים. אך זאת יש לעשות רק לגבי אותם המכלולים הנותנים שיפור ביצועים בולט אין לחדש לשם החדשנות בלבד. בדרך זו נשיג מקסימום תוצאות במינימום מאמצים. כאשר בוחנים את השיפור שייתן מכלול חדש )מסוג 2,3( לעומת מכלול ידוע )סוג 1( יש להיזהר משני מוקשים פסיכולוגיים: הנטייה הטבעית והבריאה של מהנדס פתוח להעדיף את החדש. 3 הנטייה לקבל את היתרונות של הקיים כמובנים מאליהם ולהדגיש את חסרונותיו, ומאידך להדגיש את היתרונות של מה שעדיין איננו בידינו ואילו חסרונותיו מוזנחים )אינם ידועים(. בכל מקרה אסור להכניס למערכת מכלול מסוג 4 זה מקומו בפתוח בסיסי. באשר למכלול מסוג 3 רצוי מאד לפתחו עד למציאת פתרון בסיסי לפחות לפני שניגשים לפתוח המערכת כולה )ע י כך הוא מפסיק להיות מסוג 3(. אם הדבר אינו אפשרי מחוסר זמן, רצוי לעבוד במקביל על מספר פתרונות, כדי למנוע אבוד זמן רב בגלל מספר גדול של מחזורי פתוח והפסד משאבים מרובים בפתוח הבו- זמני של יתר חלקי המערכת. לא רצוי להכניס יותר ממכלול אחד מסוג 3 למערכת, דבר זה יביא כמעט בוודאות להתבדרות לוח הזמנים ותוצאות הפתוח הקטנת הצמוד )3( השפעת אי העמידה של מכלול במפרט, בחלקו או במלואו, על מפרט המערכת ו/או על לוח הזמנים של פתוח המערכת קשורה ישירות לעצמת הצמוד בין המכלול למכלולים אחרים ולמערכת כולה )ציור מספר 2(. אם הצמוד חלש יהיה הסיכון הכרוך בהתבססות על מכלול פחות מוכר קטן יותר; לפיכך נוכל להרשות צמוד חזק עבור מכלול מסוג 1 אך מכלול מסוג 3 יש לתכנן כך שהצמוד יהיה חלש. כללית רצוי לתכנן את המערכת עד כמה שאפשר עם צמודים רופפים. אם יתברר לאחר מעשה שהיינו זהירים מדי יגרם עקרון תכנון זה למערכת תת-אופטימאלית מבחינות מסוימות )לא בבצועים(, אולם במקרה ההפוך אנו עלולים להישאר בלי מערכת בכלל. לדוגמא: נתאר את הצמוד בין מערכת הנחיה, ראש קרבי ומשקל בטיל 4 )ציור מספר 4(. מרחק ההחטאה נקבע בעיקר ע י טיב מערכת ההנחיה ובהרבה מקרים אין אפשרות להעריך אותו בדיוק מספיק לפני הפתוח ובצוע נסויי טיסה מלאים. 3. יש לנצל את הנטייה הזו במלואה בפתוח אבני בניין בסיסיות חדשות אך להזהר מההשפעה המבדרת שלה על אינטגרציה של מערכת. 4. משקל טיל מושפע מגורמים נוספים שאינם מופיעים בציור. 12

15 מערכת הנחיה מרחק החטאה ראש קרבי משקל כולל של הטיל ציור מספר 4 משקל כולל של הטיל מאידך משקל הראש הקרבי הנקבע ע י מרחק ההחטאה משפיע מאד על משקל הטיל כולו. על מנת שלא להסתכן בתוצאות פתוח מערכת ההנחיה מוטב לבחור בהערכה שמרנית של מרחק ההחטאה ולבנות טיל כבד יותר ובעל ראש גדול יותר. בסוף הפתוח עלול להתברר שיכולנו לבנות טיל קל יותר; אולם במקרה ההפוך, אם נסתמך על הערכה אופטימית של מרחק החטאה, אנו עלולים להישאר ללא נשק בכלל. 2.4 על הסיכון בפיתוח המערכת נוכל לאפיין מערכת שלמה כפי שאפינו את המכלול הבודד )סעיף 2.2.2( בהרבה מקרים אנו מפתחים מערכות מסוג 2, מנימוקים של עצמאות ביטחונית ו/או כלכלית. אולם עם הזמן ועליית רמת הפתוח בארץ גוברת הנטייה לפתח מערכות מסוג 3 ו- 4. הסיכון בפתוח מערכות אלו דומה באפיו לסכון בפתוח מכלולים מאותו סוג אך כמובן גדול בהרבה. הבעיה היסודית כאן היא בחירת העבודות והניסויים הקריטיים שיאתרו את מוקדי הסיכון ויאפשרו לקבוע במינימום זמן ומשאבים את בציעות המערכת. לרב קיימת הנטייה להתרכז במכלולים הקריטיים ולעזוב בשלב ראשון את כל השאר. בנטייה זו קיים סיכון הנובע מכך שמערכת בעלת מבנה חדש עלולה להיכשל לא רק במכלולים הקריטיים שבה אלא גם מצמודים בלתי צפויים בין חלקיה השונים ובינה לבין העולם החיצון. לדוגמא: להצלחת מערכת המתבססת על עקרון חדש דרוש מכלול חדש ולא ידוע, ועל כן מחליטים להתרכז בפיתוח אותו מכלול והוכחת בציעותו; אבל בניסוי המערכת כולה בתנאים אמיתיים עלול להתברר שכל העיקרון החדש מופרך מעיקרו! לפיכך יש לשים את הדגש בפתוח מערכת על ניסוי כולל של דגם פונקציונאלי נכון, עד כמה שהדבר ניתן, בתאריך מוקדם ככל האפשר. 13

16 קול המערכות - כתב העת של מהנדסי המערכות בישראל 3. בנית תכנית עבודה 3.1 תכנון הרשת )PERT( והשמוש בו תכנון הרשת הרגיל הנו חד כיווני ובנוי מרשת פעולות עוקבות מהתחלת המשימה ועד סופה. זה עומד בסתירה למהלך פתוח מכלול שבו מופיע מספר לא ידוע מראש של מחזורים לפני שאפשר להתקדם לשלב הבא )ציור מספר 3(. על מנת להתגבר על קושי זה ולאפשר את השימוש בתכנון רשת בפרויקט תכנון ופתוח הציע אבן )4( להגדיר את הסתברות גמר הפתוח בכל מחזור וכן את זמן הפתוח בכל מחזור )ציור מספר 5(. נקודת החלטה פתוח מכלול t = { 10, 5, 4, 4 } p = { 0.6, 0.8, 0.9, 1 } חזרה מהלך פתוח מכלול ציור מספר 5 לאחר בניית הרשת כולה בצורה זו אפשר, באמצעות תכנית מחשב מתאימה, לחשב את הזמן הממוצע לגמר פרויקט, סטיית תקן, וכו. לא ניכנס לשאלה של משמעות ההסתברויות הנ ל, וסטיית התקן לפריקת חד-פעמי, מאחר ותפקידו העיקרי של תכנון הרשת איננו לתת תחזית ממוצעת אלא להוות מכשיר שיוכל להצביע על נקודות התורפה בתכנית. על ידי כך נוכל להפנות אליהן את המאמץ הנכון בזמן הנכון. לפיכך נראה לנו )5( כמועיל יותר לפתוח את המחזורים ולהגיע לתיאור המקובל בתכנון הרשת הרגיל. בתיאור זה נניח עבור כל מכלול 2-3 חזרות בהתאם לאפיו )ציור 3 למטה,A1(.,A2 A3 לדוגמא נתאר פתוח מערכת המורכבת מארבעת המכלולים A,B,C,D )ציור 6 א (. הציור מראה שאי אפשר לבדוק את המכלולים B,C לפני ש A קיים וכן את D לפני ש-,B C קיימים. כמו כן אופי המכלולים מצביע על כך שיופיעו 2-3 מחזורי פתוח עבור כל מכלול. פתיחת המחזורים לתכנון רשת רגיל כאשר מניחים 3 חזרות עבור כל מכלול )ציור 6 ב ( נותנת תאור פסימי על מהלך הפתוח. לעומת זאת ייתן ציור 6 ג שבו מניחים רק שתי חזרות תאור אופטימי יותר. 14

17 A B D A C A 1 A 2 A 3 B 2 C 2 B 3 C 3 D 2 D 3 B 1 C 1 D 1 A 1 A 2 B 2 C D 2 2 B 1 C 1 D A 1 A 1 A 1 3 A 2 K, B 1,C 1 K, B 2,C 2 K, B 3,C 3 D 2 A 3, D 3 3 D 1 דוגמא לתכנון רשת כללי ציור מספר 6 כאשר עובדים לפי קריטריון של מינימום זמן )ראה גם סעיף 5( נתכנן את העבודה לפי העקרונות הבאים: 1 קביעת. 1 יעדים לפי הערכה אופטימית, כלומר לפי ציור 6 ג.. 2 על 2 ידי כך נוכל לנצל ללא זמן מת כל התקדמות מהירה. 3 הפעלת 3. מסלולי תיקון לפי הערכה פסימית. לדוגמא אם המכלול A מטיפוס 3 הדורש 2+ n חזרות רצוי מאד לעבוד על פתרונות במקביל. מאידך אם ניתן להחליף את A בחלק מהפתוח במכלול ידוע K נוכל להתקדם עם המכלולים האחרים ולהשאיר זמן לבדיקת מספר פתרונות עבור A בטור )ציור מספר 6 ד (. 3.2 הערכות זמנים הקושי העיקרי בהערכת זמנים בפתוח נעוץ בקושי להעריך את מספר המחזורים שיופיעו. מאידך לאחר ש פתחנו את החוג אין קושי ניכר בהערכת הפעולות הבסיסיות של תכנון, בצוע ובדיקות עבור כל חזרה וחזרה. לפיזור הרגיל בהערכות של פעולות בסיסיות ידועות, יש לרוב משמעות קטנה לעומת תוספות הזמן הגדולות הנגרמות ע י מחזור שלם נוסף או ע י צורך לחפש פתרון אחר לגמרי. בבעיות אלו, כפי שראינו בסעיף הקודם, יש לטפל באופן רדיקלי. 15

18 קול המערכות - כתב העת של מהנדסי המערכות בישראל מאידך, קורה לעיתים די קרובות שקשה מאד לקבל הערכת זמן מהימנה על פעולה מסוימת. לדוגמא אספקת פריט מחו ל שזמן אספקתו אינו ידוע או יצור חלק ע י קבלן חוץ שאינו מוכן בשום פנים להתחייב לתאריך. כאן יש לנו מקרה מובהק של פעולה שאיננה בשליטה ואין טעם לעצום את העיניים, להכניס לרשת הערכה אופטימית, ממוצעת ופסימית, להוציא את התוצאות מהמחשב ולקוות שיהיה טוב. במקרה של חוסר שליטה הכרחי לחפש ולמצוא דרך להפעלת מסלול תיקון במקביל. 3.3 על עבודה במקביל כאשר מדובר על עבודה במקביל נוכל לחלק את הבעיה לשני מקרים:. 1 עבודה 1 על שני )או יותר( פתרונות במקביל, דבר המחייב הקצאת שתי )או יותר( קבוצות פתוח נפרדות לנושא.. 2 הכנת 2 מספר דגמים או חלקים במקביל, המותנית בעיקר באמצעי הייצור. במקרה הראשון יש צורך להכפיל את כח האדם המקצועי המוקצב לנושא, אך בכח אדם כזה יש לרוב מחסור ומאידך נושאים יש הרבה. לעיתים קרובות אם כי מצהירים על עבודה במקביל, עד מהרה מסתבר שעובדים בטור בגלל מגבלת כח אדם. כאשר רוצים לשלב בפתוח מערכת מכלול מסוג 3 יש להבטיח שבאמת עובדים על פתרונות במקביל. במקרה השני הכוונה למעשה לא להכנת דגמים לפתרונות שונים במקביל, אלא להכנת מספר דגמים עם פרמטרים שונים עבור אותו פתרון. בשיטה הרגילה של בדיקת פרמטרים ע י הכנת דגמים בטור חוסכים במחיר הדגמים אך משקיעים יותר זמן עד לגמר הפתוח. מאידך ע י הכנת דגמים במקביל חוסכים זמן במחיר יצור דגמים מיותרים. יש לבדוק היטב בכל מקרה את מאזן מחיר יצור הדגמים לעומת מחיר פיגור הזמן המתבטא הן במחיר נוסף לכח אדם והן בהשפעה על כל הפתוח. פרט לדגמים יקרים מאד, התחשיב לרב מצביע שכדאי, אם קיבולת הייצור מאפשרת זאת, להכין דגמים במקביל. אנו מדגישים נקודה זו מאחר ולעיתים קרובות נרתעים מחשש פן יאמרו: בשביל מה עשית דגמים מיוחדים? 4. מגבלות תכנון לטווח ארוך כאשר מתקשים בתכנון פתוח מערכת לטווח ארוך פרוש הדבר שאין אנו מסוגלים עדיין להגדיר את המערכת בצורה סבירה. ניתוח המערכת במקרה זה יראה למשל שחלק ניכר ממכלוליה הם מסוגים פחות ידועים. לדוגמא נניח שמציעים מערכת בעלת 5 מכלולים מהסוגים הבאים: 1 מכלול מסוג 4 2 מכלולים מסוג 3 1 מכלול מסוג 2 1 מכלול מסוג 1 במקרה זה מוטב לגשת לפתוח בסיסי של המכלולים הלא ידועים מבלי לשלב אותם מיד לפתוח מערכת. כמובן שפתוח זה יש לכוון מבחינת תנאי העבודה, תחום פרמטרים וכו לשימוש הצפוי. דוגמא אחרת היא כדלקמן: 1 מכלול מסוג 3 3 מכלולים מסוג 2 1 מכלול מסוג 1 16

19 אבל המערכת כולה היא מסוג 4. כאן דרוש בראש ובראשונה להוכיח בציעות עקרון המערכת ולצורך זאת יש לעקוף במידת האפשר את המסלול הארוך של פתוח המכלולים )בעיקר של המכלול מסוג 3(. במקרים מסוג זה המצטיינים בפער ידע רב אין טעם לתכנן את הפתוח בפרוטרוט לטווח יותר ארוך מהנדרש לקבלת התשובות שיאפשרו תכנון נבון של מערכת שלמה. אמנם גם כאן יש צורך בתכנון אמצעים שיהיו דרושים בכל מקרה אם הכנתם דורשת הרבה זמן. 5. השפעת הקריטריון על תכנית העבודה עד כה הנחנו תכנון העבודה על פי קריטריון של מינימום זמן )סעיף 3( הטבעי בעיקר לפתוח צבאי. סביר להניח שע י קביעת קריטריון של מינימום מחיר נגיע לתכנון עבודה שונה, האם נכון הדבר? בהרבה מקרים מהווה כח האדם את המרכיב העיקרי של ההוצאות, כאשר במחירו נכללים גם ציוד קבוע ואוזל שבלעדיהם אין הוא יכול לעבוד. במקרים אלה ניתן ליישם קריטריון מינימום מחיר רק במשטר של Hire and fire במדינה בעלת מאגר גדול של כח אדם טכני. בתנאים שלנו עם מגבלה של כח אדם קבוע או משתנה באיטיות מביא הקריטריון של מינימום מחיר לדרישה של ניצול מיטבי של כח האדם בכל עת, כלומר לקריטריון של מינימום זמן. 6. סכום בדו ח זה ניסינו לתרום למתודיקה של תכנון העבודה בפרויקט פתוח על סמך לקחים שהופקו בתנאים מסוימים בזמן ומקום והכללתם. השימוש בהכללה זו לתנאים אחרים מחייב זהירות ובקורת מתמדת. 7. ת ו ד ה המחבר מודה למר א.תמרי שהיה לו חלק רב בגיבוש הרעיונות המוגשים בדו ח זה. 8. סימוכין: T. Marshak, T.K.Glenman, R. Summers, Strategy for R&D, Springer 1967, pp A.D Hall, A Methodology for systems Engineering D. Van Nostrad, 1962, pp Ref. 1, pp א.אבן, יישום טכניקות של רשתות חצים לתכנות תהליכי תכנון, עבודת,M.Sc הטכניון, 1968 ז.בונן, דו ח מס )מסווג( רפא ל משרד הבטחון. 17

20 קול המערכות - כתב העת של מהנדסי המערכות בישראל אנו מודים ל- IEEE על האישור לפרסם המאמר בגיליון זה. The New Taxonomy of Systems: Toward an Adaptive Systems Engineering Framework 1997 IEEE. Reprinted, with permission, from Aaron J. Shenhar, Senior Member, IEEE, and Zeev Bonen, Life Member, IEEE, IEEE Transactions on Systems, Man, and Cybernetics Part A: Systems and Human, Vol. 27 Number 2, March 1997 Abstract Systems engineering is developing rapidly, while new standards are created and new tools are being developed. However, the theoretical understanding and the conceptual foundation of systems engineering are still in their early stages. For example, although real-world systems exhibit considerable differences, there is very little distinction in the literature between the system type and the description of its actual system engineering pursuit. We suggest here a new approach to systems engineering. It is based on the premise that the actual process of systems engineering must be adaptive to the real system type. Using this concept, we present a two-dimensional (2-D) taxonomy in which systems are classified according to four levels of technological uncertainty, and three levels of system scope. We then describe the differences found in systems engineering styles in various areas, such as system requirements, functional allocation, systems design, project organization, and management style. We also claim that adapting the wrong system and management style may cause major difficulties during the process of system creation. Two examples will be analyzed to illustrate this point: the famous Space Shuttle case and one of the system development projects we studied. I. INTRODUCTION THE CREATION of complex man-made systems probably has its historical roots in early civilization. Today, with the development of management theory, such creations are often linked to modern concepts of systems engineering. As a problem-driven field, the practice of systems engineering is rapidly growing, while more standards are being written and additional tools are being developed. However, as a theoretical discipline, systems engineering is quite new and probably not well understood. Most research literature on the systems engineering process is still young and suffers from a scanty theoretical basis. Originated in the defense and space industries, attempts are being made to introduce the ideas of systems engineering into the commercial and consumer-oriented industries. However, these attempts have had only limited success, since managers and engineers in such industries do not see the relevance of defense-based systems engineering to their fields. The reason, again, is perhaps the tenuous conceptual foundation of systems engineering. One of the difficulties in developing a better understanding of systems engineering is that little distinction has been made in the literature between the system type and its strategic type, or its systems engineering and managerial problems. For Manuscript received April 26, 1995; revised March 20, A. J. Shenhar is with Stevens Institute of Technology, Hoboken, NJ USA ( ashenhar@stevens-tech.edu). Z. Bonen is with Bar-Ilan University, Besa Center for Strategic Studies, Israel. Publisher Item Identifier S (97) example, many influential project management and systems engineering texts and handbooks focus on the universal set of project management activities such as organizing, planning, controlling, and monitoring [8], [16], and systems engineering tasks such as requirements analysis, functional allocation, trade studies, and system synthesis [4], [7], [14], [23]. Several exceptions should be mentioned, however [2], [3], [6], [28], [31]. In practice, as most project managers assert [22], there are great differences among systems and among the processes of their creation. Consider, for example, the case of building a new cross-city highway, as compared to the development of a new space vehicle, or the case of making a new model of a small appliance such as a coffee maker, as compared to the effort of building the English Channel tunnel. Naturally, these efforts are called projects, and they may employ some system engineering procedures; however, it is clear that their differences outweigh their resemblance. Although some distinctions among systems have been mentioned previously, from a conceptual perspective, the following question still remains open: do all systems look alike, and, for that matter, are all systems engineering processes really the same? This paper is based on our ongoing field study of recent years, that has so far collected data on more than 250 projects in the United States and Israel. Data was collected in the defense and the commercial sector, and in a variety of industries such as aerospace, electronics, computer, mechanical, chemical, and construction. The purpose of this study was to identify the differences among systems, to investigate contingencies in the processes of system creation, and to develop a conceptual foundation for the distinction among systems and projects. Our basic proposition is that both project management style and systems engineering practice differ with each specific kind of system and that management attitudes must be adapted to the proper system type. Our methodology was based on a combination of qualitative and quantitative methods encompassing the process of building theory from case study research and traditional statistical analysis based on data accumulated through structured questionnaires. We suggest a conceptual 2-D taxonomy for the classification of systems. In our framework, systems are classified according to their technological uncertainty at the moment of project initiation and system scope which is their location on a hierarchical ladder of systems and subsystems. After presenting the basic model, we will describe some highlights from our study as they relate to systems engineering. In particular, we will outline the differences that were found in systems engineering practices between different system types. We will 18

21 Fig. 1. A 2-D taxonomy of engineering projects and systems. then use several famous projects to illustrate the virtue of our framework. We will also discuss two cases of system misclassification. They are the famous Space Shuttle program and one of the system development projects in our study. II. THE 2-D TAXONOMY Innovation literature has often used a traditional distinction between radical and incremental innovation [1], [3], [9], [10], [12], [32]. Radical innovation is frequently based on new technology, and it often results in products new to the firm and new ventures unrelated to existing businesses. Incremental innovation, in contrast, introduces relatively minor changes in existing products, and generally takes the form of product modifications, upgrades, derivatives, and line extensions. As our studies revealed, this low high dichotomy is insufficient to capture the full-spectrum of engineering tasks [26]. The first dimension is based on levels of technological uncertainty as perceived by the organization at the time of the project s initiation [13]. It includes four different levels, designated as: A low-tech, B medium-tech, C high-tech, and D superhigh-tech. The second dimension is based on the complexity of the system as expressed by the different hierarchies inside a product. Since products are composed of components and systems of subsystems, hierarchies in systems may include many levels [5], [25], [29]. However, our findings exhibit a predominant split between three clusters of engineering project styles. The dimension is called system scope and it includes the following three designated levels: assembly, system, and array (see Fig. 1). III. SYSTEM CLASSIFICATION, SYSTEM CHARACTERISTICS, AND SYSTEMS ENGINEERING STYLES How could systems be classified according to the 2-D model, and what are the distinct system characteristics, systems engineering, and management styles used for different kinds of systems and projects? As found, different concerns characterize the two dimensions. In this section, we define the different types of systems and describe the associated managerial and systems engineering characteristics. These characteristics are summarized in Tables I and II. A. The Technological Uncertainty Dimension 1) Type A Low-Tech Projects: Type A projects are those projects that rely on existing and well-established technologies to which all industry players have equal access. Although such projects may be very large in scale, no new technology is employed by the firm at any stage. Typical projects in this category are construction, road building, and other utility works that are common in the construction industry. The main characteristic of this kind of project is that no development is required and usually no system testing is conducted. The system requirements are usually set by the customer prior to signing the contract and before the formal initiation of the project execution phase. System functional requirements are usually simple and straightforward, and are often static. The design cycle of such systems is usually characterized by a single cycle and no design iterations are performed, while the final design of the system is usually frozen prior to the project initiation. The management and systems engineering style of low-tech projects can be described as a firm and formal style, in which one should stick to the initial design, and no changes are allowed or required. 2) Type B Medium-Tech Projects: Type B projects rest mainly on existing technologies; however, such systems incorporate a new technology or a new feature of limited scale. Typical projects of this kind include engineering efforts of incremental innovation, as well as improvements and modifications of existing products and systems. They may involve new models in well-established product lines, such as automobiles or consumer electronics; they can also include defense projects that involve upgrades of existing systems. Such projects are found in almost all industries including mechanical, electronics, aerospace, and chemical. Medium-tech projects require some development work and some testing. Their requirements are mainly set in advance; however, some changes may be introduced during the product development phase. This process often involves a joint effort of the contractor and customer. It may also require the involvement of potential customers in the process. The system s required functions, although still simple, are more dynamic than in low-tech systems, and often include more than one mode of operation. The design cycle of such systems would frequently consist of more than one iteration, and the final system design is usually fixed early, normally during the first quarter of the project. The style of these projects can be described as moderately firm; however, it is more flexible than in type A projects. More communication both formal and informal is also required, since more tradeoffs and changes are made. 3) Type C High-Tech Projects: Type C projects are defined as projects in which most of the technologies employed are new, but existent having been developed prior to the project s initiation. Many projects in the high-tech industry that involve a new family of products or a new technology generation produce products of this kind. Similarly, most new defense development efforts would normally be characterized as high-tech system projects, incorporating new technologies that have been recently developed [11]. Typical industries are electronics, computers, and aerospace. 19

22 קול המערכות - כתב העת של מהנדסי המערכות בישראל TABLE I SYSTEM CHARACTERISTICS BY LEVEL OF TECHNOLOGICAL UNCERTAINTY Integrating several new technologies for the first time obviously leads to a high level of uncertainty and risk. Type C projects therefore require extensive development and testing efforts, and building of several prototypes along the way. System requirements are derived interactively with a strong involvement of customers or potential users, and many changes are introduced. Functional allocation is complex, and functions are dynamic and multimodal. The design cycle of these systems is also iterative, usually entails two or more cycles, and the system design freeze takes place at a later stage than in type B systems. It often occurs as late as the second quarter or the midpoint of the project. The systems engineering and management style of high-tech systems can be described as moderately flexible, since many changes are expected and are a natural part of this type of system development. It involves intensive interaction and the use of multiple formal and informal communication channels. 4) Type D Super-High-Tech Projects: Type D projects are based primarily on new, not entirely existent, technologies. Some of these technologies are emerging, others are even unknown at the time of the project s initiation. The project s execution period is, therefore, devoted in part to the development of new technologies, testing, and selection among alternatives. This type of development project obviously entails extreme levels of uncertainty and risk; it is relatively rare, and is usually carried out by only a few and probably large organizations or government agencies. Typical products are the development of a new nonproven concept, or a completely new family of systems, and they are usually confined to the few leading electronics and aerospace industries. The most 20

23 TABLE II SYSTEM CHARACTERISTICS BY SCOPE LEVEL known example of such a project was the Apollo moon-landing mission [21]; however, other smaller scale projects can also be found in this category. Type D projects require extensive development both of the new technologies and the actual system. Their development frequently requires building an intermediate, small-scale prototype, on which new technologies are tested and approved before they are installed on the prototype. System requirements are hard to determine; they undergo enormous changes and involve extensive interaction with the customer. Obviously, the system functions are of similar nature dynamic, complex, and often ambiguous. A super-high-tech system is never completed before at least two, but very often even four, design cycles are performed, and the final system design freeze is never made before the second or even the third quarter of the project. To summarize, the management and system engineering style of these projects can be described as highly flexible to accommodate the long periods of uncertainty and frequent changes. Managers and engineers must live with continuous change for a long time; they must extensively increase interaction, be concerned with many risk mitigation activities, and adapt a look for trouble mentality. B. The System Scope Dimension 1) Scope 1 An Assembly: An assembly is a collection of components and modules, combined into a single unit. A typical assembly may perform a well-defined function within a larger system, hence constituting one of its subsystems; 21

24 קול המערכות - כתב העת של מהנדסי המערכות בישראל it can also be an independent, self-contained product that performs a single function of a limited scale. A radar receiver, a missile s guidance and control unit, or a computer s harddisk are common examples of assemblies (subsystems) within larger systems; compact disc players, coffee makers, washing machines, and other household appliances can be considered independent assemblies of the second kind. Such products are either functioning as autonomous, or they require only a limited amount of human interaction. The creation of assemblies is usually performed within one organization, and often under the responsibility of a single functional group. It involves mostly technical people with limited staff support or no staff at all. Systems engineering in assemblies is mostly concerned with design related issues such as design for manufacturability, reliability, etc., and much less with total system organization. The core of the systems engineering activity is the process of concurrent engineering and the involvement of crossfunctional teams. Resources planning is relatively simple, with no more than 100 activities in the network or PERT, and it is often performed manually. Control is simple as well; it often involves reporting only to top management or main contractor, with the majority of documents being technical rather than managerial. In essence, therefore, managing the creation of an assembly is usually made in an informal way, using a team, or family-type style. 2) Scope 2 A System: A system is a complex collection of interactive units and subsystems within a single product, jointly performing a wide range of independent functions to meet a specific operational mission or need. A system consists of many subsystems (and assemblies), each performing its own function and serving the system s major mission. Radar, computers, missiles, and, for that matter, entire aircraft are typical examples of systems performing independent tasks. Systems are capable of performing a complex mission, and their use involves considerable man-machine interaction. Organizing a system project usually involves a main contractor who establishes a project management team and who is, in turn, responsible to managing and coordinating many internal and external subcontractors. The management team includes technical personnel, administrative staff, and systems engineering people. The systems engineering at this level encompasses the activities at the lower level, but it primarily involves most of the traditional aspects, such as system requirements, functional allocation, system synthesis, and tradeoffs. One of the major difficulties in the system level is the problem of system integration, and that of achieving an overall optimized and effective system. The systems engineering process at this level also requires a detailed systems engineering management plan. Planning resources in a system project is a complex activity. It requires advanced and computerized tools, since the system development network may include hundreds or even thousands activities. Control both managerial and technical must be tight and formal, and extensive technical and administrative documents are used, usually according to a formal standard. For example, one of the major concerns is configuration control and configuration management to keep track of all the changes and detailed baseline of design. In summary, management style of system creation must be greatly formal and bureaucratic; however, some informal relationships always develop at this level between the management team and some subcontractors and customers. 3) Scope 3 An Array: An array is a large collection of systems functioning together to achieve a common purpose. Different terminology for an array may be a supersystem, a system of systems, or the Greek word systema, all being an expression of the array s nature as a conjunction or conglomeration of systems. Arrays are usually dispersed over wide geographical areas and normally include systems of many kinds. A nation s air defense system, consisting of early warning radar, command and control centers, combat aircraft and ground to air missiles, is a good example of such a super system. Similarly, the public transportation network of a large city, or the city s highway system, may also be considered typical arrays. Arrays achieve wide-range missions, based on the simultaneous functioning of many systems, and their operation involves the association and interaction of many people. To manage the effort of building or even improving an array, a program management office is usually established as an umbrella organization which coordinates the efforts of various system project organizations. This office is usually staffed with legal, administrative, and finance experts who provide the proper control in each discipline. This office is usually less occupied however, with technical matters; those are left to the separate projects. It is also much less concerned with system integration. Sometimes the leading organization is hiring another system house organization to be the super-system integrator. Many system engineering efforts are directed toward ensuring coordination among various system projects. Another major concern of array projects involve environmental and government regulations, which are becoming critical due to the dispersed nature of the final product. Planning such projects is done through a master central plan, which is followed by detailed planning at the systems level. The total number of activities may reach tens of thousands, and project planning tools are often inadequate for planning purposes of array projects. In fact, array projects normally develop their own tools for planning, coordinating, and control. Most central control in these projects involves managerial and financial issues, and they require extensive amounts of documentation. Finally, the management style of such a program is primarily formal, bureaucratic, and tight, since the central office is usually remote from the separate projects, and most of their connections are formal and in written form. IV. INTEGRATING THE TWO-DIMENSIONS INTERACTION EFFECTS As discussed above, when moving from lower to higher technology systems while keeping the system unchanged, the concerns of managers and engineers are shifting toward additional technical issues: more design cycles, more testing, and longer periods of ambiguity in requirements and specifications. Similarly, increased scope with constant uncertainty results 22

25 in additional concerns for formal administrative issues: more planning, tighter control, more subcontracting, and more bureaucracy. When, in addition, one moves simultaneously along both dimensions, from low- and medium-tech assemblies toward high-tech and super-high-tech systems and arrays, new challenges must be addressed, and, as found, there is a strong interaction effect between the two dimensions. First, it is at this end of the model that systems engineering is practiced at its best. The development of large multidisciplinary systems, which consist of many subsystems and components, involve the incorporation of most modern systems engineering tools and processes to optimally harmonize an ensemble of subsystems and components. Such tools are almost not present in low-tech or medium-tech system projects. System engineers in high-end projects are a natural part of the management team, and they are responsible for creating the system s architecture and configuration and incorporating a multitude of technologies that must cohere in the final design. They are also accountable for the system s reliability, maintainability, supportability, human factors, and economic feasibility of the entire engineering effort. In lower-tech systems, assembling, integrating, and testing all subsystems into one unit is usually not an issue, since all pieces readily fit together. Integration difficulties become prominent, however, in the higher uncertainty type system projects. In these projects, the successful production of the separate subunits is one thing, while integrating them into one working piece is another. Problems of interfaces, energy dissipation, electromagnetic interference, and even lack of space, require long and tedious processes of assembly, numerous tests, and necessary trade-offs in many of these projects. Finally, there are problems of configuration and risk management. Special software must be used in high-uncertainty high-scope projects to keep track of all the decisions and changes, and to identify the potential interactions that would occur with each change. Such projects develop a cumulative database for their design baseline, which, in some cases, must be updated on a day-to-day basis. As for risks, although all projects involve a certain level of risk, higher-scope highertech projects are more sensitive to the need for sytematic risk analysis and risk mitigation. In such projects, a risk management procedure is usually integrated into the program. It often involves issues of design control, personnel qualifications, procurement management, quality control, and budget and schedule control. V. A RETROSPECTIVE CLASSIFICATION OF FAMOUS PROJECTS Several famous projects can be easily coded according to this paper s classification. For example, IBM s project of building the personal computer in the early 1980 s would be characterized in this framework as a high-tech system development project, since it was based on new but existent technologies. Similarly, development projects of defense systems such as the Patriot missile are usually based on recent technologies that were developed prior to the main project effort. Such projects are normally contracted following a wellstructured procedure of defense acquisition to contractors that demonstrate a viable capability and sufficient maturity of technologies. Other examples of high-tech projects are the development efforts of the first generation of videocassette recorders introduced by JVC and Sony in the mid-1970 s [24]. However, according to our framework, it is an assembly. Lockheed s SR-71 Blackbird reconnaissance aircraft was initiated in the late 1950 s with no clear technology available, and almost no known configuration [15]. Retrospectively, we may classify it as a super-high-tech system. New York City s transit authority capital program of modernizing the city s transit infrastructure would be classified as a low-tech array [20]; the English Channel tunnel is a medium-tech array, since it involves some new challenges and risks of digging such a long undersea tunnel [18]. Finally, the U.S. strategic defense initiative, or as it was often called Star Wars [17], is the only example we could site of a super-high-tech array development program. VI. CONSEQUENCES OF MISCLASSIFICATION Systems engineering and program management must be conducted according to the proper style and be adapted to the system type. Such style should be chosen according to the classification presented above. In that sense, one may see the above discussion as a description of project and system ideal types. When the proper style is employed, we claim, that the chances for project success are much higher. However, when a wrong style is utilized, or the when the system is misclassified, this may result in substantial difficulties and delays in the process of the system creation. For example, working on a project perceived as type C, when it is really a type D, may lead to problems which are beyond the competence within the framework of the organization. It may require higher technical skills, additional resources, longer periods of development and testing, and much later design freeze. On the other hand, when a project is actually a type C, and it is wrongly perceived as type D, many overruns and difficulties may be attributed to technology, while they are simply the result of bad administration and weak leadership. To illustrate some of these difficulties, the framework of this work will be used to analyze the style and management of two system development projects. A. The Space Shuttle Program On Jan. 28, 1986, the space shuttle Challenger took off on its last mission, tragically exploding just 73 seconds into launch. The tragedy shocked the American nation and seriously damaged NASA s image, which had been built on a history of 25 years of continuous success. The shock of the tragedy was followed by months of investigation, and it has been widely analyzed in many articles and other writings. Using the model presented in this paper, we suggest a new way of looking into the Shuttle program. It is based on the proposition that from its inception, this ambitious system was designed and managed while employing the wrong management and systems engineering style. We also claim that a proper classification at project initiation would have led to a different systems engineering style and culture, and might have helped eliminate many of the circumstances which eventually led to the Challenger tragedy. 23

26 קול המערכות - כתב העת של מהנדסי המערכות בישראל The space shuttle was designed to enable man to function in an extraterrestrial environment by using the same vehicle on repeated flights. The program was first proposed in 1969 following the successful Apollo moon landing as an element of an interplanetary transportation system that would enable the United States to land a crew on Mars in the 1980 s. At that time, however, the enthusiasm and space competition that characterized the Apollo era had gone, and the shuttle s initial high-cost proposals encountered low priorities. NASA officials discovered that their main hope of winning congressional support for the shuttle in the atmosphere of indifference and skepticism of that time was to emphasize its cost effectiveness, namely, its reusability and its low development price-tag. The notion became that this new innovation could be built almost entirely within the state-ofthe-art, largely from off-the-shelf parts which either existed or could be readily fabricated. The space agency s projection of the shuttle was simply that of a space-adapted airplane, and this was expressed by saying: We have the technology, we have the skills, we know how to build it [19]. Eventually, a moderate, low-cost reusable space shuttle program was approved and its final configuration was selected in The shuttle s first orbital flight was scheduled for 1978 while the shuttle fleet was to become operational in The program involved three major components: the orbiter, which is powered by three main liquid hydrogen oxygen rocket engines, the external tank which carries the liquid fuels for the orbiter s main engines and is not reusable, and two solid rocket boosters which supply the main thrust at liftoff. It is clear now that NASA s initial attitude toward the space shuttle project was one which in our notation would be classified as a type C. The belief, however, according to which this invention could be built almost entirely within the state-of-the-art, based on existing technologies, turned out to be unrealistic. The problem of building such a huge vehicle that can function effectively in two different mediums, both in space and in the atmosphere, was too difficult to accomplish, using the success-oriented attitude [30]. Eventually, the program suffered overruns amounting to almost three years in schedule delays and 60% in unexpected costs, all accumulated even before the first flight. The following list demonstrates some of the main risks that existed at the beginning of the project: 1) It was the first vehicle which was designed to fire hydrogen oxygen engines at ground level in the proximity of an external fuel tank and to be reused again at least 50 times. 2) Although NASA had already been using solid-fuel vehicles for launching small unmanned spacecraft, solid boosters for manned flights was a technology new to the agency. 3) Never before had such a large winged space aircraft reentered the atmosphere. 4) Never before had a 75-ton glider descended through the entire regime of hypersonic and supersonic speeds to make a pinpoint landing 5000 miles from the point of reentry. 5) NASA had no prior experience in reusable thermal protection materials. 6) Never before had a manned space vehicle undergone its first orbital flight with a live crew. 7) Finally, the shuttle was to become the first American space vehicle without a crew escape system. Developing the space shuttle turned out to be one of the most difficult and exasperating engineering challenges of the space age, if not the most difficult of all. Engineering and design problems encountered during the development phase were enormous, as illustrated by the following two examples. First, there were problems involving the main engines. These engines were expected to be fully developed by 1977, but between Mar and Nov there were 14 engine test failures caused by faulty seals, uneven bearing loads, cracked turbine blades, and many other defects. Eight of the failures resulted in fires which damaged the engines or the test-stand. NASA s early commitment to the initial design, based as it was on a success-oriented strategy, made it imperative to keep going, even when Murphy s law took over and anything that could have failed actually did. What was missing in this part of the program was a prior, much longer experimental phase of separate testing of the new technology of high-pressure hydrogen oxygen engine components, before bringing the fully assembled engine to the test-stand [19]. The second example relates to the thermal protection difficulties. The main thermal protection of the orbiter was made of special tiles using a new material which had never been tested on any previous space vehicle. Its main problem appeared to be the stability of the tiles installed. Each one of the tiles was different, and it had to be manually installed by skilled craftsmen. After the first vehicle was flown from California to Florida, thousands of tiles were missing and many others failed the pull tests conducted to examine their stability. The thermal protection turned out to be a nonstable add-on to the orbiter structure, causing the agency many disruptions and continual delays. In retrospect, this shield should have been built into the vehicle s structure, rather than glued in as an add-on. Had the agency run earlier flight tests, perhaps on a smaller scale reentry vehicle, it might have chosen a different solution to the thermal protection problem than the one that was initially selected [19]. These and many additional problems encountered during the shuttle s development phase did not change NASA s initial go ahead attitude, and in 1982 under the pressure of demands for an intensive flight rate, the shuttle s fleet was declared operational, a state for which, in many respects, the system was not prepared [30]. In retrospect, although at the time of the Shuttle s approval NASA was under severe pressure to cut costs, it seems that the program should have been managed using a different philosophy. In the context of this paper, a type D system management scheme was probably more appropriate than the one actually used. If such a philosophy had been used, then the final configuration selection, the freezing point of the design, and the operational declaration would have been scheduled for a much later point, leaving open the possibilities of using other, 24

27 more thoroughly tested, and perhaps improved technologies. In addition, a type D philosophy would have vested the program managers and engineers with a different systems engineering attitude toward risks, possible development problems, and probability of failure, and would have created the need for a much higher level of communication among the various parties involved. Returning to the Challenger tragedy, we may note here that the presidential commission that investigated the accident confirmed that it occurred because of a leak of a vaporized material out of the right solid rocket booster. This leak caused a flame that resulted in an enormous explosion. The commission concluded that the failure was the result of faulty design of an aft field joint, which was unacceptably sensitive to factors such as temperature, physical dimensions, the properties of the materials, the effects of reusability, etc. The commission also concluded that the decision to launch the Challenger was wrong. Those who made that decision were unaware of the recent history of problems concerning the o-rings on the joint and were unaware of written recommendations of the contractor against the launch at temperatures below 53 F. Among its recommendations, the commission suggested performing a new design of the faulty solid rocket motor joint and seal and forming an independent solid rocket motor design oversight committee. The commission also recommended reviewing the shuttle program management structure, redefining the program manager s responsibilities, reviewing all critical items, performing hazard analyses, establishing an office of safety, reliability and quality assurance, and improving communication among various NASA s units and subcontractors. Looking back on the shuttle s program after the accident, one cannot help but ask whether if NASA had adopted a different attitude toward the program, this tragic accident would not have occurred? Of course, we may never know. What we may say, however, is that if the agency had initially employed a managerial form that is closer to a type D style, it would have scheduled many of its decisions related to technology and configuration to a later data, and, as mentioned, it would have adopted a different and a much more intense communication pattern inside the program. It would certainly not have conducted this program by using the success-oriented approach, and would have been more keenly aware of the possibility of trouble. One must note however that when the space shuttle program was approved and its budget set, NASA was under extreme pressure from the administration to prove the system s costeffectiveness and to considerably cut development expenses. Under such circumstances, NASA abandoned its initial plan to build a small-scale test vehicle to make certain it had all the technology in hand before embarking on a full-scale vehicle. But these circumstances probably also nurtured in the agency the success-oriented type C attitude that prevailed in the program since its inception. B. A New Military System Development Project The second case is a research and development project we investigated during the course of our studies [27]. The goal was to develop a new aiming and control system to be installed on an existing military platform. Previous experience of the main contractor with earlier generations of this kind of system was not sufficiently indicative of the level of complexity and difficulty associated with this project. Consequently, the project management team chose a traditional management style. It turned out, however, to be a completely new experience to the firm, particularly in terms of integrating new technologies for the first time. As it turned out, the project went into a serious crisis and was saved only after significant reconstruction and a change of managerial style and attitude, and only after substantial overruns occurred. We maintain that a careful early analysis of the project characteristics could have led management into a different style right from inception and would have helped to save considerable resources. Using our framework in retrospect, our analysis shows that the project should have been classified as a high-tech type C system level project. The initial management attitude that was employed on this program could be seen, however, as that of a medium-tech type B assembly project. Most of these projects are usually improvement or modification efforts entailing only minor advancements in-terms of technology, and they involve building separate units without much regard to their interaction. The project proved to be much more complicated and it required, in fact, a more careful design and an increased level of flexibility in management style as required by type C system projects. The difference can clearly be seen when looking at the initially scheduled time for design freeze which was set at a very early stage of the program, and was in sharp contrast to the actual, much later, time when the design was finally frozen. The second problem emerged during the system integration phase. The integration stage was not sufficiently predicted, and even not planned for in detail until after it had started and initially failed. The initial assumption was that this phase would be short and simple. The first subsystems and units systems were indeed supplied on time, after they had been subjected to partial, nondynamic testing. However, when assembled together onto the final platform, they did not meet many performance requirements. The consequences required renewed system engineering, additional feasibility studies, and redevelopment of two of the subsystems. The result was extensive budget overrun and schedule delay. In conclusion, the main problem lay in misclassification of the project s initial uncertainty and misevaluation of its scope. In the developer s initial estimation, the system was nothing more than an add-on improvement to a system of a previous generation. Similarly, the complex link between various system components, and between the system and platform, was almost completely ignored. The failure to predict the technical and integration difficulties resulted in a managerial and technical crisis to which only extensive top management support helped the project to become a success after all. VII. CONCLUSION Systems engineering is a wide-range activity, and it should not be handled in the same form for all kinds of systems. Above all, system engineering requires a proper attitude, 25

28 קול המערכות - כתב העת של מהנדסי המערכות בישראל concept, and philosophy. To design and manage systems effectively, one must choose the appropriate concept and adopt the right attitude. Only then can one choose the specific tools and practices for executing the project. In this paper, we have suggested classifying systems into four classes according to their level of technological uncertainty and into three classes of system scope. Each class requires a different concept and a distinctive philosophy for effective systems engineering and management. The framework given here is not conclusive; it could be further refined and investigated. For example, one may consider additional uncertainties for the analysis of system management market uncertainties, for example. In this case the uncertainty dimension may represent a different kind of uncertainty and would require different skills. There is also a need for more work in order to develop better and more advanced tools for system engineering in specific classes of systems. Researchers in the field of engineering and management science, as well as practitioners and consultants, may find the framework of this work useful for seeking additional insights into the managerial differences among systems, and for finding better and more effective ways to manage the creation of different kinds of systems. [20] S. J. Manne, and L. Collins, Reconstructuring an aging infrastructure, Project Manage. J., Apr. 9 24, [21] C. R. Pellegrino and J. Stoff, Chariots for Apollo. New York: Athenaeum, [22] J. K. Pinto and J. G. Covin, Critical factors in project implementation: A comparison of construction and R&D projects, Technovation, vol. 9, pp , [23] E. Rechtin, Systems Architecting. Englewood Cliffs, NJ: Prentice-Hall, [24] R. S. Rosenbloom and M. A. Cusumano, Technological pioneering and competitive advantage: The birth of the VCR industry, Calif. Manage. Rev., vol. 24, no. 4, pp , [25] A. J. Shenhar, On system properties and systemhood, Int. J. General Syst., vol. 18, no. 2, pp , [26] From low to high-tech project management, R&D Manage., vol. 23, no. 3, pp , [27] A. J. Shenhar and S. Alkaher, Meeting the high technology system integration challenge: The BAT project case history, working paper, Center for the Development of Technological Leadership, Univ. Minnesota, Minneapolis, [28] L. W. Steele, Innovation in Big Business. New York: Elsevier, [29] J. P. Van Gigch, Applied General Systems Theory, 2nd ed. New York: Harper and Row, [30] F. Webster, The space shuttle Challenger incident: Showcase project, Project Manage. J., vol. 18, pp , June [31] S. C. Wheelwright and K. B. Clark, Revolutionizing Product Development. New York: Free Press, 1992 [32] G. Zaltman, R. L. Duncan, and J. Holbek, Innovations and Organizations. New York: Wiley, REFERENCES [1] W. J. Abernathy and J. M. Utterback, Patterns of industrial innovation, Technol. Rev., pp , June/July [2] N. Ahituv and S. Neumann, A flexible approach to information system development, MIS Quart., pp , June [3] S. B. Blake, Managing for Responsive Research and Development. San Francisco, CA: Freeman, [4] B. S. Blanchard and W. J. Fabricky, System Engineering and Analysis, 2nd ed. Englewood Cliffs, NJ: Prentice-Hall, [5] K. Boulding, General systems theory: The skeleton of science, Manage. Sci., vol. 2, pp , Apr [6] J. I. Cash, Jr., W. F. McFarlan, and J. L. McKenney, Corporate Information Systems Management. Homewood, IL: Irwin, [7] W. P. Chase, Management of Systems Engineering. Malabar, FL: Krieger, [8] D. I. Cleland and W. R. King, Systems Analysis and Project Management. New York: McGraw-Hill, [9] R. D. Dewar and J. E. Dutton, The adoption of radical and incremental innovations: An empirical analysis, Manage. Sci., vol. 32, pp , [10] J. E. Ettlie, W. P. Bridges, and R. D. O Keffe, Organizational strategy and structural differences for radical vs. incremental innovation, Manage. Sci., vol. 30, pp , [11] R. J. Fox, The Defense Management Challenge: Weapons Acquisition. Boston, MA: Harvard Business School Press, [12] C. Freeman, The Economics of Industrial Innovation, 2nd ed. Cambridge, MA: MIT Press, [13] J. R. Galbraith, Organization Design. Reading, MA: Addison-Wesley, [14] J. W. Hunger, Engineering the System Solution. Englewood Cliffs, NJ: Prentice-Hall, [15] C. L. Johnson and M. Smith, Kelly: More Than My Share of It All. Washington, DC: Smithsonian, [16] H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 5th ed. New York: Van Nostrand Reinhold, [17] R. M. Lawrence, Strategic Defense Initiative. Boulder, CO: Westview, [18] J. K. Lemley, The channel tunnel: Creating a modern wonder of the world, PmNetwork, July 14 22, [19] R. S. Lewis, The Voyage of Columbia. The First True Spaceship. New York: Columbia Univ. Press, Aaron J. Shenhar (S 74 M 76 SM 86) received five academic degrees in electrical engineering, statistics, and engineering economic systems from the Technion Israel Institute of Technology, Haifa, and Stanford University, Stanford, CA. He is now Institute Professor of Management at Stevens Institute of Technology, Hoboken, NJ. He has 20 years of business and management experience in a high-technology environment. In the business world, he has managed the development of several high-technology projects involving radar and computer technology. As executive at Rafael, the Armament Development Authority of Israel, he was Corporate Vice President and President, Electronic Systems Division. Since beginning a second career in academia, he has been involved in teaching and research in the areas of technology and innovation management, project and product development, systems engineering, and the management of professionals in high-technology organizations. He has published three books and more than 40 refereed articles. He is a recognized consultant and well known speaker in technology-based organizations such as 3M, Honeywell, Loral, the Trane Company, and Israel Aircraft Industry. Zeev Bonen (A 51 M 56 LM 92) was born in Jerusalem, Israel, in He received the Electrical Engineer degree from the Technion Israel Institute of Technology, Haifa, in 1951, and the Ph.D. degree in nonlinear control from Cambridge University, Cambridge, U.K., in From 1952 to 1979 and 1981 to 1989, he was with Rafael, the Armament Development Authority, Israeli Ministry of Defense. He served as President of Rafael from 1970 to 1978 and 1982 to He has published many papers on weapons development and on the evolution of battlefield systems. Since his retirement in 1989 he has engaged in various consulting activities. Since 1994, he has been Senior Research Fellow, Bar Ilan University Besa Center for Strategic Studies, Israel. In 1970, Dr. Bonen received the Israel Defense Prize for the development of the Shafrir air-to-air missile. 26

29 Issues in Man Made Systems Theory Introduction Dr. Zeev Bonen Systems engineering is an essential discipline for the implementation of man made systems (MMS), called also artificial systems. Its role is to transform MMS requirements into concrete systems. All engineering disciplines are based on scientific disciplines, e.g. electrical engineering is based on physics, chemical engineering on chemistry etc. Thus, the discipline of systems engineering also requires a base of relevant and applicable theory of MMS systems, which often include both equipment and human operators. It includes the evolution of systems, driven by new technologies and changing missions. The theory should be oriented towards the needs of the systems engineer (SE). It will be an essential part of systems engineering body of knowledge (Kasser and Massie, 2001). In addition, the SE must have a specific knowledge base, relevant to the systems he is involved with. The need for an overall theory of MMS is pressing, because the world of Man Made Systems is growing rapidly, creating an increasing variety of systems with different dimensions and attributes. Hence, the task of the SE in selecting the activities relevant to the system he is working on, is becoming more and more difficult. The theory described in this paper tries to address this situation, in order to facilitate the tasks of the SE. The paper begins with a description of the requirements (Sec.2) and the framework of man made system theory (MMST) (Sec.3). Systems basic properties are described in Sec.4.1, followed by a detailed discussion of systems structures (Sec.4.2.) and evolution paths. System structures include inanimate systems, and systems of systems (SoS) in which, by their definition, humans are incorporated within the system. Inanimate systems had been the main concern of systems engineering, during its evolution over more then half a century. SoS have emerged later (Adm. Owens 1995, Bonen 1984). This paper focuses on SoS, which have some important specific features, discussed in detail. The inclusion of humans (Sec.4.4) in SoS requires addition of new methodologies and tools. In addition, SoS evolve over a long period, which often includes many generations of inanimate systems and people; hence it is necessary to discuss their long term evolution paths (Sec ) Also, SoS are dispersed, hence they must use connecting networks to tie their parts together. Thus, a system and its networks are complementary. Historically, systems theory and network theory have evolved separately. Here, they are combined as necessary for the requirements of SoS. Sect 5 deals with networks structures and evolution paths. Sect. 6 deals with the interactions between systems and networks. Note that an adaptive system cannot exist without adaptive networks which form the necessary links (Sec.6.4.) between its components. 27

30 קול המערכות - כתב העת של מהנדסי המערכות בישראל A main requirement for a theory, of man made systems, is the existence of laws. These include laws of nature and man made laws (Sec.7). Sec.8 deals with the implementation of the theory to the tasks of inanimate and animate systems engineering. The last section suggests some areas for future research. 1.MMST Requirements The main requirements for MMST are: Relevant to the tasks of the SE. Its framework must cover and support a large and increasing variety of systems. Deal with the long term evolution of systems. Fulfill basic requirements of a theory. Open and evolvable. Part of the academic discipline (framework and contents) of systems engineering. The systems approach stresses the major role of systems and their interactions, at all levels in the universe. Essentially, a system is holistic; the whole system is more than the sum of its parts. Systems engineering, which deals only with MMS, transforms the systems approach into an engineering discipline. Systems engineering may be applied to systems within a specific engineering discipline, e.g. water systems engineering or chemical systems engineering. But, more generally, its main role is in engineering of heterogeneous and complex systems. Due to the increasing variety of such systems, and also of methodologies and tools to serve the SE, the tasks of the SE in selecting the relevant activities, methodologies and tools, is ever more difficult. MMST is intended to facilitate selection of the relevant tasks by: Mapping the multi - dimensional MMS world into cells or classes of systems with shared attributes and similarities. A sequential navigation process, which will guide the SE, from project description to the selection of present relevant activities and elaboration of their contents. At present, systems engineering focuses on the life cycle phases of an inanimate system project from need identification to system disposal. On the other hand, this paper focuses on the characteristics which embody the essential differences between inanimate systems and SoS: The inclusion of humans inside the SoS, which enables the creation of far more complex and adaptive systems. Gradual evolution over a long period. Understanding and coping with the problems and processes of the long term evolution of SoS, is of great importance. SoS dispersion requires the use of connecting networks to tie their parts together. Thus a system and the various networks used by it are complementary. In particular, an adaptive SoS cannot exist without adaptive networks. 28

31 Last but not least, in order to qualify as a theory, MMS theory must fulfill basic requirements for a theory. It cannot be just an empirical description of a body of contents within an agreed framework. Only when empirical results are embodied in laws, it will qualify as a theory. These laws must cover and support a large and increasing variety of systems. Also, these laws should enable, in many cases, prediction of probable future evolution of systems. In addition, MMS and the laws governing them evolve over time. Therefore, MMS theory must be open and evolvable. 2. MMS Theory Framework Main Subjects The theory framework includes: Inanimate systems and systems of systems (SoS). Evolution of SoS. Role of humans. Networks and their interactions with systems. Theory laws and their implications. Implementation of theory. The addition of a course of MMST to the academic teaching of systems engineering, will provide an overview of the MMS world and the properties of various classes of systems, guiding the SE to the actual tools relevant to him. 3. Systems 3.1. Basic Properties Abstract systems are built with two basic elements: Nodes and the links connecting them. Physical systems are built to perform a set of missions, by using a combination of physical nodes and links; the nodes or modules, using various processes, perform the transformation of inputs into outputs. The links transmit a variety of entities between modules or sub-systems. The module itself is also a system with an internal structure. There are two types of modules: Inanimate and human. Most dynamic physical systems can be constructed using these two elements. Larger systems have more components. A heterogeneous SoS contains a variety of different systems, inanimate and human modules connected by a variety of links. The links are provided by Networks which are also systems, are constructed from the same basic elements. But networks have a specific mission: To transmit a variety of entities between users. Transmission may include the transfer of materials, people, power and information via the links, using various media and formats. Due to their specific mission, networks configurations and links distribution patterns, are quite different from those of systems. Systems structures can be permanent or flexible; that is with the capability to replace, add or delete nodes and links. This capability enables system adaptation within an adaptation range. Obviously, this capability can lead to a major change in basic system structure. 29

32 קול המערכות - כתב העת של מהנדסי המערכות בישראל System size is defined here by the number of its nodes or modules. System complexity is defined by: The number and the distribution of links between the modules, i.e. by link density. Hence, it is determined by the link configurations of the networks serving the system. This definition applies also to inanimate modules internal complexity. The inclusion of various types of human modules (sec.4.4) often leads to far greater system complexity Structure Systems Layers Systems are divided here into five main layers: 1. Inanimate systems and subsystems, activated and often also controlled, by an external human operator, e.g. a radio. Once activated, such systems are autonomous and automatic. 2. A Managed SoS integrates various inanimate systems and human controllers together, produce or operate a complex system, e.g an air defense system. There are many levels of such systems. Thus, an air defense system which comprises many anti-aircraft batteries and warning systems can operate at many levels: local, regional, and global. 3. A population of independent managed SoS without central management A population of independent, unmanaged systems and actors, e.g. the Internet. Regulation and control systems setting and enforcing the rules of the game on lower level systems. The division of the layers depends on several characteristics: The role of the human being in the various layers. At the lowest layer he is an external operator of the inanimate system. In all the higher layers, humans are included inside the system. The two lowest layers deal with single systems. Layers 3,4 deal with a population of independent systems. Layers 1,2,3 consist of managed systems. Layer 4 contains unmanaged systems. The main layers presented in Table 1 are derived from the Hitchins five layer model [Hitchins 2003] with some modifications. 30

33 Table 1 The Main Layers Compared Bonen Hitchins 1. Inanimate Systems 1. Product Layer 2. A Managed SoS 2.1 Engineered Systems 2. System Layer 2.2 Producing Organizations 3. Business Layer 3. Population of Independent Managed SoS 4. Industry Layer 4. Population of Unmanaged Systems and Actors 5. Regulation & 5. Regulation & Control Systems Control Layer A few notes on this table: 1. The population of unmanaged systems (Bonen #4), requires a separate category. They are self-organizing systems, which probably require an additional methodological tool box. Note that this layer includes also political and economic systems. These are beyond the scope of this paper. 2. Managed SoS (Bonen #2) contains both the engineered systems and the organizations which produce them. The latter sometimes require total system intervention when their inputs and/or missions undergo major changes. 3. A Population of Independent Managed SoS (Bonen #3), may include various types of systems (Competing, Hostile, Friendly, Cooperative, Support) SoS Definitions Traditional systems engineering focuses on the lowest layer in Table 2 Inanimate systems. Systems including humans, i.e. SOS, are located in layer 2. According to Sage: (Sage 2007), SoS are defined by following characteristics: Elements include Organizations. People. Processes. Products (Inanimate systems). Usually dispersed over a large area. Sub-Systems can survive and perform by themselves useful missions, even if disconnected from the higher levels of the SoS, in short they are stable sub- Systems. This is a federation of divisible stand alone Systems. 31

34 קול המערכות - כתב העת של מהנדסי המערכות בישראל My definition (Bonen 1984) stresses the major role of people as an essential part of the SoS. It includes also monolithic, indivisible systems. In any case, the inclusion of people inside a system requires also the application of soft methodologies, in analysis and synthesis. These are not necessary for the analysis and synthesis of hard inanimate systems. Hence, SoS engineering is different in many aspects from traditional system engineering. (This paper is devoted mainly to SoS Engineering.) SoS are dispersed, hence they must use connecting networks to tie their parts together. Thus a system and the various networks used by it, are complementary. Indeed, the structure of a system depends a great deal on its networks. In particular, adaptive networks are essential for system adaptation. This subject will be discussed in Sec System Boundaries and Environment A system exists within, and interacts with, its environment. System boundaries are defined by its external missions, e.g. the mission of a ground to air homing missile (an inanimate system) is to hit a single hostile aircraft. But, as a part of an air defense SoS, it interfaces and cooperates with other components of the air defense system. The missions and boundaries of this SoS are by far more extensive. On the other hand, many disconnected SoS sub-systems can survive independently and perform by themselves useful missions, within smaller boundaries. The environment is not only the natural environment. A system usually operates within a specific artificial environment, where it interacts with other systems. These includes various types of systems: Competing. Hostile. Friendly, cooperative, complementary. Support. All systems belonging to a specific artificial environment co-evolve together Role of Humans (Bonen, Bustnay 2008, lec.4) Inanimate systems, once activated, execute a limited number of well defined missions, within a limited envelope. Humans, on the other hand, can handle complex situations; identify unexpected events and patterns in a complex, noisy environment and create new, relevant responses. Hence, the inclusion of humans enables far greater system complexity. A SoS combines inanimate systems with human flexibility to create more sophisticated complex systems. But, the analysis and synthesis of SoS are more difficult; it requires tools that engineers are not familiar with and are often reluctant to use. The human operates as a module, which performs transformations of inputs into outputs. Usually the human operates within a functional entity: The extended human module shown in Fig There are also extended human teams models, where team members interact personally and via equipment. 32

35 Decision Aids and Displays Human Operator Actuating Mechanisms Fig The Extended Human Module A human can play a variety of roles with increasing freedom of action: Operator ( Robot ) with a limited dictated menu e.g. an operator in a chemical plant. A Controller can handle a large pre-prepared menu. An Actor, capable of making complex unpredictable decisions, has a large freedom of action e.g. an aircraft pilot. A Free Actor capable of unpredictable behavior. Human potential is prominent as actor and free actor. A major problem in the design of the architecture of a SoS, is the proper combination of humans and inanimate systems. The problem is where to insert humans in the SoS and in what roles. In some locations, it may be possible to select for the same task, either a suitable extended human module or an inanimate autonomous module. There are two main selection types: Simple selection. In a dangerous environment where humans cannot survive or is in life danger. an inanimate module is preferable, if it can be built from available and proven technologies. n a complex environment human advantages, as an actor or free actor, are paramount. Complicated selection. Here it is possible to select for the same task, either a suitable extended human module or an inanimate autonomous module. The selection depends on many criteria such as: Availability and quality of personnel, availability of legacy inanimate modules. Complicated selection is probably the most difficult problem in the design and evolution of a SoS architecture. The evolution of technologies increases incrementally the capabilities envelope of existing inanimate modules and also leads to the creation of new inanimate modules with far better and even completely different capabilities. 33

36 קול המערכות - כתב העת של מהנדסי המערכות בישראל 3.5. System Dynamics Systems evolve in response to changes in missions, technologies and the natural and artificial environments. These processes occur in both managed and self-organizing systems Inanimate Systems Life Cycles The evolution of Inanimate Systems proceeds by replacement of generations. A life cycle of a specific inanimate system is shown in Fig.3.2, upper level. During its life time it may be upgraded by inserting new technologies, and also adapted to serve changing requirements. Sooner or later, it will be replaced by a new generation (Fig. 3.2, lower level). In many cases replacement will be driven by new technologies offering radical change, i.e. major increase in present system capabilities. Inanimate Systems Life Cycles Interaction Between Generations 1st Generation Life Cycle Phases Feasibility Study FSD IOC FSC Upgrading End of Service New Technologies Incremental Changes Radical Change Feasibility Study 2 nd Generation Life Cycle Phases FSD IOC FSC Upgrading End of Service Fig.3.2. Inanimate Systems Life Cycles SoS Adaptation and Evolution (Bonen, Bustnay 2008, lec.7) An adaptive system can change rapidly in response to fast changes in its missions and environment, within a specific adaptation envelope. The adaptation process may be temporary or permanent; it involves addition or deletion of, immediately available modules or network links. Note that some changes can lead to system degradation and even to system collapse. Hence, a menu of permissible adaptation changes, must be prepared of line. The role of networks in adaptive systems is discussed in Sec.6.4. Beyond the adaptation envelope, existing systems can evolve via various paths, driven by changes in technologies which create new modules and links, and also by changes in the environment. Changes in the natural environment are usually slow, but changes in the artificial environment and system missions can be quite rapid. The main paths are shown in Fig.3.3. The common incremental change path involves a sequence of incremental changes leading to a somewhat better version of the same system. Sometimes, it may lead to higher performance within a smaller envelope, i.e. to adaptive specialization. However, when missions or the environment undergo rapid, large changes, such adaptive specialization leads to a dead end and system demise. 34

37 Note that incremental change is common, due to the constraints imposed by several types of inertia: physical, organizational, conceptual and cultural (Details in Sec.7.2). Inertia plays major roles in system evolution: A positive role in preserving system robustness and stability by dampening the effects of small disturbances. A negative role when radical change is required. In most cases inertia, which channels evolution towards incremental changes often delays the necessary radical change until it is too late. Radical change leads to a major increase in system capabilities or even to a transition to a completely different capabilities envelope. It requires new structure and operating processes. Radical change can proceed via several routes: The creation of a new system, driven by new technologies and/or by changes in missions and the environment (Natural and artificial). A slow metamorphosis, by a sequence of incremental changes, of an existing system. Often, such a slow process cannot cope with the pace of change in the environment, leading to system demise. Fast change driven by a sudden crisis; it can be based only on readily available equipment. Crisis can also trigger faster evolution of technologies. Evolution of Technologies and Systems Crisis Creation of a New SoS Combined Radical Change Existing SoS Evolution of an Insertion of New Systems Radical Change in SoS Use of Available Components Only Conceptual Design of a New SoS Structure, Processes, Systems Incremental Change No Change in Structure and Processes Combined Development Process Pilot SoS integration and Evaluation Large Scale Implementation Radical Change Metamorphosis of Existing SoS Protracted Radical Change Recovery and Survival Wrong Change, too Slow, too Late Decline and Demise Specialization Smaller Envelope Dead End and Demise Large Changes in Environment Fig System of Systems Evolution Paths The Life Cycle of a SoS The life cycle of a SoS usually begins with the formation phase of the system, the creation and initial implementation stage of the new system (The radical change 35

38 קול המערכות - כתב העת של מהנדסי המערכות בישראל path, Fig.3.3 left). Later the system evolves gradually over many decades until its downfall (The incremental change path in Fig.3.3). The whole life cycle is summarized in Fig.3.4. Formation Phase Of a New SoS SoS Incremental Evolution Phase Radical Change And Survival Decline and Downfall Fig.3.4 System of Systems Life Cycle The formation stage process begins with the invention of a concept for a new innovative SoS, offering radical change (Fig.3.5). The conceptual design of the SoS configuration, combines legacy systems, new and future equipment, human operators and processes in an initial architecture. The concept is first of all, evaluated in a combined computer simulation of the SoS and its equipment. Later, the combined development process follows two parallel, interacting paths: Equipment development and SoS development. These two paths interact via multi-directional information flow through an iterative multistage process. They are integrated and tested together in field experiments. In the early stages, equipment which is not yet available, is represented by surrogate equipment; or in hybrid field experiments where the surrogates reside in the laboratory. During the lengthy development process, improvements and new generations of such inanimate systems, are inserted from time to time. Towards the end, a small complete pilot SoS is tested in the field followed, if successful by initial and full scale implementation. New Technology Equipment Development Equipment Tests Invention of a New Concept Combined Simulation Integration and Tests of Pilot SoS Large Scale Implementation Changes in missions and Environment SoS Development System of Systems Tests Fig The Combined Development Process of a New SoS 36

39 Later the SoS evolves incrementally over many decades. During this long period the equipment is improved or replaced by new versions, via the equipment path. But, there is almost no change in the SoS configuration path. Infrequently the system succeeds in accomplishing radical change by slow incremental metamorphosis. In this case, the combined evolution process described in Fig.3.3 must be re-activated. But, in the majority of cases slow metamorphosis fails, leading to system decline and demise. In conclusion it is extremely important to try to identify as early as possible the technological opportunity and the changes in the artificial environment, which call for radical change. Successful identification should lead to the activation of the combined evolution process described in Fig System Evolution Risks Overview The implementation of system projects requires analysis and management of many types of risks, depending on system status and internal properties and on the changing conditions outside the system. They include: Internal risks (Technologies and Processes). Present Market Risks. Long term risks. Crisis risks. The first two are known unknowns, i.e. risks in known problem areas. The latter are unknown unknowns, i.e. unknown risks in unknown problem areas. They may emerge gradually after many years and even decades. But, such risks can also emerge suddenly tomorrow. System Risks include inanimate modules risks and SoS risks. These are located in layers 1&2 in Table 1 (Sec.3.2.1). As defined in Sec.3.1, modules perform the transformation of inputs into outputs by various processes. Hence, inanimate modules include inanimate systems & subsystems Inanimate Modules Technological Risks Inanimate modules development risks include market risks, which will not be discussed here, and technological risks. The technological risk level of an inanimate module, often based on several technologies. depends on the available know-how in these technologies. They can be ranked in a ladder of increasing risks (Bonen 1969, 1971). 1. Technology well known and used in the organization. 2. Technology well known and available in the world, but does not exist in the organization. 3. Technology exists in the world, but no details are available. 4. Non-existent technology. Level 1 & 2 technologies can be used to upgrade a subsystem of an existing inanimate system and also in a new generation of the system. Level 2 technology must be assimilated in the organization, before it can be applied to a module. 37

40 קול המערכות - כתב העת של מהנדסי המערכות בישראל Level 3 & 4 technologies should not be used in an ongoing inanimate system project. They should be developed separately, if in the future they would apparently contribute to many applications. Such development is often intended to achieve an advanced technology demonstrator of a module or a sub-system. Risks in an inanimate system depend on the changes in its performance envelope. In a new non-existent system with a new performance envelope, risks are higher. In upgrading of an existing system, the risk levels depend on the size of changes in its performance envelope SoS Risks Introduction: Risk levels and evolution overview System of systems (SoS) level risks can be ranked similarly to technological risks: 1. Present SoS tasks well known and practiced. 2. Well known SoS which have been proven in the world. 3. SoS exists in the world, but no details are available. 4. Non-existent SoS. Risks at the SoS level depend on SoS properties and status. The risks during the formation stage of a new system differ from the risks during the evolution of an existing SoS over many decades. New SoS Evolution Risks The creation of a new SoS, which does not exist anywhere, even if based on existing inanimate and extended human modules, may involve level 4 risks. The risk level may be estimated by differences from existing SoS of similar size (System size was defined in Sec. 3.1, by the number of nodes or modules), such as: Large change in performance envelope. Changes in architecture, i.e. changes in links (Type, number, location, strength). Changes in modules (Substitution, addition, deletion). Any or all of these differences, may indicate unknown level 4 risks. Some may be uncovered during preliminary simulation before initiation of the project. More unknown unknowns will surface only during the SoS combined evolution process (Fig.4.5. above). Existing SoS evolution risks After the initial formation and successful deployment of a new system, it will evolve, slowly and gradually, over many decades. Two major unknown unknown risk areas: external long term and crisis risks, will be discussed now. 38

41 Long term SoS risks According to the SoS definition by Sage (Sec ), such systems are composed of stable autonomous sub-systems, capable of operating and evolving independently. Thus they have the property of evolvability. Interoperability is also necessary to facilitate this process. This approach applies when basic shifts, in the artificial and natural environments, are slow and gradual. enabling slow system adaptation to a new emerging major scenario. Usually, such a scenario does not appear overnight. It can and should be perceived and prepared for years ahead of its actual sudden appearance in a crisis. But, if neglected it will become a crisis risk. Crisis Risks According to Hastings (McManus, Hastings 1996), Long term risks result from: Basic shifts in user needs are usually caused by unknown unknowns such as unexpected missions and adversaries in defense, or new markets or sources of competition for civil systems. In addition to evolvability and interoperability, flexibility is essential, that is the capability to address unexpected completely different missions, sometimes required by a new scenario, not originally included in the requirements. Crisis risks are unexpected sudden events, i.e. unknown unknowns. Flexibility, i.e. rapid adaptation to crisis, which enables operation within an extended or a completely different performance envelope, can be based only on existing, readily available flexible means: Modules and links. Such adaptation also requires interoperability; it may increase linking complexity, temporarily or permanently. It has been suggested, that long term system evolution can lead to a system, capable of flexibility of operations within several different long term future scenaria. Such flexibility requires fast aggregation under crisis, of system components suitable for the actual scenario. In practice, this requires training of personnel in the all specific aggregations required for the defined long term scenarios. Such training may create confusion. Practically, there is never enough time for training in all the aggregations. Basically it is a problem of human inertia, especially in the higher levels of the hierarchy. The most difficult issue is fast conceptual change between scenaria, in response to a sudden crisis. Hence, it is difficult to achieve crisis flexibility, for several different long term future scenaria. Dealing with System Risks - Summary Dealing with System Risks involves mapping, analysis and risks management. It should deal with all relevant system levels; also it includes risks in several time frames: Presently perceived (known unknowns) risks. Future long term unperceivable (unknown unknowns) risks. Crisis risks which can appear suddenly tomorrow. 39

42 קול המערכות - כתב העת של מהנדסי המערכות בישראל Presently perceived risks require immediate attention, particularly for the next stage or two, of the present system development cycle. Future long term slowly evolving unperceivable risks are dealt with by ensuring system evolvability, interoperability and flexibility. Dealing with a sudden crisis at some unknown future time, can be based only on existing, readily available means. Hence, a sufficient reserve of equipment must be prepared well ahead. Crisis management is difficult. It is by far more difficult if it is desired to prepare for a fast transition to one of several surprise scenario. In any case a well practiced emergency management organization must be ready. 4. Networks 4.1 Definitions, Structure and taxonomy Systems are built in order to achieve a mission or a set of missions. Networks are also systems, constructed from the same basic elements: nodes and links, but they have a specific mission: To transmit a variety of entities between users. Transmission may include the transfer of materials, people, power and information via the links, using various media and formats. A network connects single users and sites containing a number of users. A private network serves a specific system or organization. Often called intranet. A public network serves all interested users, e.g. the road network or the internet. Many public networks are managed, e.g. the road network. Others, like. the internet, are not managed. Hence, they are self-organizing, but still regulated. In most cases, public networks can not be split, by the disconnection of a single link. The network map structure depends on several interacting factors: The location and importance of sites the sites map. Network Type. Geography. Links types. Technology. The structure of the sites or terminals map and also the nature of the links depends on the network type: The road transportation network - The roads are fixed links, influenced by geography. Sea Transportation The sites are fixed, determined by the location of ports, but the links are flexible. Ships may use a variety of routes between the same destinations. Air Transportation Similar to Sea Transportation. All three are geography dependent Global communication networks, e.g. the Internet, which are practically free from geographic restrictions. These networks created the Flat World of Thomas Friedman. The evolution of technology influences network sites, routes and equipment. 40

43 4.2. Networks Dynamics Managed Networks Evolution Trajectories (Bonen, Bustnay 2008, lec.8) Network adaptation is somewhat similar to rapid system adaptation. It involves, addition or deletion, of presently available flexible links. Also, it may be temporary or permanent. Network expansion to a new area, in order to serve the needs of new sites and users, may proceed in two paths: By using existing technologies, or by introducing new technologies. In the second path, the new area serves as a pilot and experimental network, connected by suitable interfaces to the older existing network. Long term evolution of networks, can lead to radical change, by implementing new technologies, to serve long term evolving needs of users and users sites. It may utilize several paths: An experimental pilot network, built by the existing network, in a new area. Gradual and incremental evolution of the existing network; By a sequence of limited local or partial replacements of old modules and links (Fig.4.1, right). The outcome of such a long, slow process, may be radical change. e.g. The ongoing transition to very fast trains in Europe. Creation of a new competing network (Fig.4.1, left) using new technologies to offer different or much better services in all or some areas. e.g. the rapid evolution of cellular telephone networks. Creation of a New Network Combined Radical Change Conceptual Design of a New Network Evolution of Technologies and Systems Development and Integration of a Pilot Network Evolution of an Existing Network Network Expansion Evolution by Incremental Changes Components Addition/Replacement Network Expansion Large Scale Radical Change Faster Radical Change by Adoption of New Technologies Protracted Radical Change Full Success? Yes New Network Flourishes Ol d N e t wo r k Di s a p p e a r s or Limited to a Niche No Symbiosis Cooperation or Merger Full Success?` Yes Old Network Flourishes New Network Disappears or Limited to a Niche Fig Networks Evolution Paths In some cases the older network succeeds, despite its large inertia, to adopt the new technologies and flourish. In others, the new competing network may win and take over the entire area served by the older network. But, in many cases, both will co-exist, in all or some areas, offering complementary services (Fig.4.1, bottom). 41

44 קול המערכות - כתב העת של מהנדסי המערכות בישראל In managed networks, old and new, the evolution path and the detailed processes are selected and controlled by the management and planners. Obviously, this is not the case in unmanaged networks Unmanaged Networks Evolution A major example of an unmanaged man made network is the internet. It evolved from the DARPANET managed closed network into the public, unmanaged but regulated, huge internet. It has been shown empirically that the connections distribution of the map-free internet, is expressed by the following power law distribution of k. Where k is the number of connections of an existing node. Later, theoretical work had shown that this power law emerges from the rule of preferential attachment (Dorogovtsev 2003, pp.28-30), which governs the connection of new users to the internet. According to this rule, the probability that a new user (node) will link with an existing node, increases as the number of connections of that node (= k) increases. This rule leads to the above power law distribution of k. This distribution has a small number of nodes with many connections, called hubs; thus it expresses mathematically, the common tendency towards centralization. This tendency, which favors evolution centralization during the process of evolution, exists also in map constrained networks, which cannot adhere to preferential attachment. Also, it exists in managed systems and networks. Some problems of centralization will be discussed in Sec Robustness and Collapse P(k) ~ k - ~ 3 Robustness is the capability of a network to handle various random or deliberate disturbances, which may disrupt its normal operation or even paralyze it completely. The outcomes of the disturbances include: Normal performance is not affected. Degraded performance. Fragmentation into stable subsystems capable of autonomous local performance. Collapse One disturbance paralyzes the network completely or partially. There are many causes of collapse. In the internet, for example, the cause of collapse arises directly from its adherence to the rule of preferential attachment, expressed by the above connections distribution equation.. Assuming that the internet is an infinite network, it has been shown that it has zero collapse threshold (Dorogovtsev 2003, pp ). A virus entering the internet at any point, can paralyze this world wide network extremely rapidly. In mesoscopic, heterogeneous, map constrained networks, there are various collapse thresholds depending mainly on the location of the disturbance, e.g. collapse thresholds in large power grids. These grids combine a population of independent power companies in one very large unmanaged regulated network. But, in most cases, such regulated 42

45 networks have had no effective mechanisms for preserving robustness, i.e. preventing drift towards low or zero thresholds. Also lacking were rapid effective mechanisms for location, containment and separation of hit areas. This common situation, led to the collapse of many large power grids across the world, causing extensive blackouts and large damages. One major finding from blackouts investigations, was the necessity for stronger central control. Paradoxically, that means that, in order to prevent total collapse, a large regulated, unmanaged network must be managed to some extent. A suitable structure is probably a federation of autonomous networks, possessing rapid and slow central control arrangements. This is similar to the federation of systems described in Sec Note that such a large dispersed federation of systems depends on quite a number of interacting networks, geographical and hierarchical. These must be designed to prevent propagation of disturbances, leading to collapse. 5. Systems and Networks 5.1. The Integration of Systems and Networks A large, dispersed hierarchical system, must link its modules by using available private and public networks. Indeed, a SoS is formed by the integration of its components via its networks. In short, it is a Modular Networked Hierarchy. The interconnection between systems and networks is illustrated by the example of the road transportation system of systems (Fig.5.1). This SoS is in charge of the various activities required for the proper operation of the present roads network, including maintenance and enforcement of its regulations; It is also responsible for the ongoing and future development of the roads network., which is used by various users: Single users, humans and freight transportation companies. The transportation companies often use private communication networks. Road Transportation SoS Maintenance Network Development Enforcement Operations Roads Network Single Users Systems of Systems Humans Transportation Companies Freight Transportation Companies Fig.5.1. The Road Transportation System of Systems 43

46 קול המערכות - כתב העת של מהנדסי המערכות בישראל Note, that there are also various communication networks which are not shown in Fig Comparison of Systems and Networks evolution Rapid adaptation, in both systems and networks, including adaptation under crisis conditions, is constrained to readily available equipment. The slow gradual process of incremental evolution is also similar, but the end results are usually quite different. Most networks will achieve radical change via the slow process of incremental evolution. On the contrary, most existing systems, attempting radical change will fail. This conclusion is due to the differences in inertia. Large networks have a large physical inertia, i.e. a large investment in network infrastructure and equipment. On the other hand, network radical change usually does not require major changes in personnel operational behavior. i.e. it is not hampered by human inertia. In systems the role of physical inertia is in most cases smaller; but a radical change in human behavior is often required, i.e. there is a large human inertia or resistance to change. Hence, an existing system has a smaller probability of survival when radical change is needed Centralization vs. Autonomy in Networks and Systems As described in Sec there is a common tendency toward centralization. Many factors push in this direction such as: Short term economic efficiency. Hubs are often a collection of interacting complex modules capable of combining many inputs by complex transformations into a diversity of new outputs.. Control or domination of a hierarchical network. But there are also some factors pushing toward decentralization and autonomy of subsystems such as: Evolution considerations will be discussed in Sec.6.2. Operational considerations Operational considerations often dictate the necessity for adaptation to and suitability for variable local conditions. In addition, autonomy enables a subsystem to operate independently in its local area, even without help from or connection to the whole system. In order to achieve autonomy a subsystem must possess the necessary capabilities. The conditions leading to and the means required for autonomy are well known. The issue is stressed here, because the common tendency of evolution towards centralization often prevails, even when the situation calls for decentralization and autonomy. Under crisis, the performance of a centralized system may degrade drastically or even collapse. 44

47 5.4. Interaction and Co-evolution As we have already seen (Sec.5.1), a dispersed system links its modules by using available private and public networks. The links may be permanent or changeable. The capability to change links is crucial for the creation of adaptive networks, which are an essential part of adaptive systems (Sec.3.5.2). Public networks may be used by many users to create their own networks, permanent or changeable. The specific type of networks used is determined by the type of served system, e.g. a power system or a transportation system. Hence, the design and evolution of a specific type of system depend on the capabilities of relevant existing networks. Unsatisfied systems needs drive the long term gradual evolution of existing networks, and also the creation of new networks, private and public. In a nutshell, this means the Coevolution of systems and networks Co-evolution risks The life cycle of a SoS (Sec.3.5.2) usually begins with the formation stage of the system. Later the system evolves incrementally over many decades until its downfall. Here we shall focus on co-evolution risks during the formation stage of a new SoS. The development process of the formation stage (Fig.3.3), combines two parallel, interacting paths: Equipment development and SoS development. Here, we shall add a third path the network path (Fig.5.2). Note that the sources of a new concept Equipment Technologies Equipment Development and Tests Changes in missions and Environment Invention of a New Concept Combined Simulation Integration and Tests of Pilot SoS Large Scale Implementation SoS Development and Tests Network Technologies Development and Tests of Network Figure 5.2 The Expanded Combined Development Process of a New SoS include also network technology. A major advance in network technology may also lead to the invention of a new SoS concept, even if there is no change in equipment. The risk levels in network technologies are the same as those of equipment technologies (Sec.3.6.2) i.e.: 45

48 קול המערכות - כתב העת של מהנדסי המערכות בישראל Technology well known and used in the organization. Technology well known and available in the world, but does not exist in the organization. Technology exists in the world, but no details are available. Non-existent technology. In the beginning of a new SoS development, only level 1 & 2 technologies should be included. Later, during the lengthy formation development process and also during the incremental evolution period, new maturing equipment and network technologies may inserted in the SoS. Over time, there is a tendency to use more and more public networks, e.g. the internet instead of intranets which are private networks. The three paths in Fig.5.2 may, in principle, be combined in several ways: Equipment and SoS. Network and SoS. All three combined. But in the real world, over the long life cycle of a SoS all three co-evolve together. In order to reduce co-evolution risks, it is preferable to insert changes in one path at a time; with minimum direct impact on the others. The steps of this process will be discussed in Sec Emergence in Systems and Networks Emergence leads to the appearance of new properties in various types of systems and organisms. The scope of the discussion here is limited to single managed or self organized man-made systems. It does not include a population of systems (Table 1, Sec ). Emergence can occur due to a variety of changes in an existing system, or by creation of a new system. Some examples of types of changes are: Changes in structure, e.g. the appearance of a new upper level in a hierarchy. The appearance of new elements: Modules and links; often due to the appearance of a new technology or a cluster of reinforcing technologies. Change in time perspective: From the development of a single system generation to the evolution of successive generations or to the continuous evolution of system of systems. Emergence is often described as a property specific to self-organizing systems, which evolve spontaneously, through various changes, as is the case in the evolution of living organisms and unplanned cities (Johnson 2001). However, it is also a property of managed and designed systems, where changes are selected by the system architect. Indeed, radical change (Sec ) in a managed system always leads to new system properties. 46

49 New properties emerge, via a variety of changes, for two main causes: To counter large changes in the system environment, which threaten its survival. This is a reactive response. To exploit new opportunities, e.g. new technologies. This is a proactive response. e.g. the application of television homing technology to the radical transition of air attack of ground targets: From short range inaccurate dumb bombs to precision stand off guided missiles and bombs. Emergence does not always lead to a more complex system. It can also lead to system break down into independent simpler systems. From the variety of possible changes, those which ensure survivability and improve performance prevail survival of the fittest. In managed systems, the process of emergence follows the evolution paths (Fig.3.3) selected by the process architect (Sec.7.1). Sometimes the selected paths. lead to successful radical change. In self organizing systems, global macro properties arise from the interaction between lower level entities following local micro rules. e.g. the rule of preferential attachment, which governs the connection of new users to the internet. Unfortunately this rule led to the emergence of the flawed macro property of zero collapse threshold. 6. Laws of Man Made Systems (MMS) Theory 6.1. Basic Requirements of MMS Theory In order to qualify as a theory, MMS theory must fulfill basic requirements for a theory. It cannot be just an empirical description of a body of contents within an agreed framework. Only when empirical results are embodied in laws, it will qualify as a theory. These laws must cover and support a large and increasing variety of MMS. Also, these laws should enable, in the majority of cases, prediction of probable future systems evolution paths. MMS laws govern and constrain the processes of systems evolution; they define the probable dynamic trajectories of a system from one stage of development to the next one. Thus, they will shape existing structures and create new structures. Last but not least, as the world of MMS and its laws evolve over time, MMS theory must be open and evolvable. Laws relevant to MMS, include: Laws of Nature, the only laws applicable to inanimate systems. Evolution of Systems laws. Laws of various disciplines related to individual and group human behavior, such as economics and sociology theories and the process of preferential linking in the evolution of networks theory. These are probabilistic laws. All the above laws are derived by scientific methods from empirical observations. In addition there are great many 47

50 קול המערכות - כתב העת של מהנדסי המערכות בישראל Laws made by humans. These laws include formal laws and regulations, rules and procedures; and also informal laws or accepted modes of behavior, namely, social norms. The basic difficulty on the road towards a comprehensive holistic MMS Theory arises from the inclusion of humans inside systems. Indeed, it may not be possible to achieve such a theory. Nevertheless, even a partial theory on basic laws influencing the evolution of systems, which plays a central role in MMST, may be quite useful. These are the following ones: Survivability. Physical and Human Inertia. Human Behavior Properties Survivability Survivability depends on the basic tendency of every system to survive in its everchanging environment. Survivability requires fast evolvability to ensure survival of the fittest systems under fast changes in environment. This is similar to natural evolution in biological systems. This law has a major structural implication. It had been shown (Simon 1969, pp ) that fast evolvability is a property of hierarchical structure systems with stable subsystems (e.g. Federation of Systems, Sec.3.2.2, Sage 2007). The same applies to almost decomposable structures with weak or easily cut links across the hierarchy (i.e., loose couplings). But, there is a most important difference between the high survivability of hierarchical structures and the very low survivability of specific hierarchical systems. While complex man-made structures have been hierarchical for thousands of years (Yitro, Moses father in law, Exodus 18:13-25), and very few man-made systems have survived for a very long period (e.g. the Catholic Church); almost all specific hierarchical systems survive only for a limited period, because they have a great deal of inertia Physical and Human Inertia Inertia plays a major role in system evolution (Sec.3.5.2): A positive role in preserving system robustness and stability by dampening the effects of small disturbances. A negative role when radical change is required to survive large disturbances in the natural or artificial environment. In most cases, inertia channels evolution towards incremental changes, often delaying the necessary radical change until it is too late. There are several types of inertia: Physical The ballast of investments and expenditures made in the past in existing inanimate equipment and the long delay in the introduction of new equipment. Organizational Large changes in organization, which disrupt present roles and procedures, are often met by strong resistance to change. Conceptual Thought is 48

51 usually constrained by the dominance of present concepts and modes of operation, which often prevent the adoption of new concepts. Cultural The prevailing culture is probably the most important factor. Changes in organization culture are very slow. The last three are manifestations of the prevalent human resistance to change Human Behavior Properties Man is a social animal, which is inclined to live in groups. This inclination evolved because of the necessity to aggregate into a group, also called a team, in order to carry out missions, which cannot be executed by a single person (e.g., hunting a large animal, using various tools). In other words, the necessity to work together in order to accomplish a mission, has probably led to the evolution of the innate human capability to work tightly together in a small group within a small area. Social evolution has expanded this capability to aggregation of groups, often dispersed over a large area. The evolution of the aggregation of groups, which enables humans to perform increasingly complex missions proceeded apparently in several stages: A small, temporary, single mission group. A small, permanent, organized group capable of performing a package of similar missions. The formation of increasingly complex structures, having the flexibility of performing a variety of different complex missions, by division of labor into simpler tasks and their integration in a suitable hierarchical structure. The effective performance of complex human structures depends on the composition of and the interaction between group cooperation and individuals motivation. The proper combination depends on system missions and its environment. When missions and the environment undergo large changes, the combination must change (e.g., the privatization and disintegration of Israeli Kibutzim). Note that, as man-made structures increase in complexity, their inertia also increases, amplifying resistance to change. Are there limits to complexity of man-made structures? Further research is required on this problem (Sec.8.3) Laws Made by Humans and Their Implications These laws include formal laws and regulations, rules and procedures, and also informal laws or modes of accepted behavior. Some formal laws formalize and detail basic system characteristics (e.g. rules and procedures of a hierarchy). Other formal laws may restrict or shape behavior in order to serve a variety of objectives (e.g. regulation and control of MMS, see Table 1, Sec.3), or selection of individuals motivation schemes. Informal laws or modes may also restrict accepted behavior. Any of these may contravene the basic characteristics influencing the evolution of systems, causing a serious damage and even demise of a system. Among these laws and accepted 49

52 קול המערכות - כתב העת של מהנדסי המערכות בישראל behavior modes, the most important and hazardous ones are those which interfere with the requirements for: Stability and robustness. Survivability. Hopefully, when large changes in man-made systems are considered, they should be examined in relation to the above requirements. But, in the real world this is often not feasible. In any case, such changes may involve high short-term and long-term risks. 7. Theory Implementation 7.1. Functions and Roles in the Development of Systems The design, planning and implementation of a system project includes several functions as defined by Kasser (Kasser 2005) System Architecture responsible for the design of the functional and physical architectures. System Engineering responsible for the technical implementation of the design. Process Architecture responsible for planning the processes required for creating the system. Project management responsible for managing the implementation of the required process. The number of participants in the project team, and the division of activities between them, depends on project size and complexity. In smaller projects it may include less then four persons, when several functions are performed by the same person. Here we shall concentrate on the role of the system engineer. The essential role of the SE, according to Sage (Sage 2006), is Transdisciplinary, i.e. to outline and implement the technical process of creating the integrative system knowledge. Transdisciplinarity activities include: Understanding and integrating heterogeneous knowledge from many disciplines. Translating and mediating discussions between professionals in various disciplines. Managing the process of fusing various perspectives into integrative system knowledge. Thus, the SE is the knowledge manager, responsible for the development and accumulation of the integrated system design, and also for designing and implementing, the on-going processes required for creating the system. Thus, the functions of system engineering and process architecture should not be separated; they have to be executed by the same person or team. 50

53 7.2. Implementation Overview why mapping and navigation The world of MMS is growing rapidly, creating an increasing variety of systems with different dimensions or attributes. Hence, the task of the SE, of selecting the activities relevant to the present phase of the system he is working on, is becoming more difficult. A useful theory should map this constantly growing world into entities which the SE can digest more easily with relevant processes and methodologies. In order to facilitate his task, the multi-dimensional systems world is mapped by the following three dimensions: Structure. Life Cycle Phases ( LCP). Risks Levels. This three-dimensional map follows, with some changes, the Hitchins-Kasser-Massie framework (Kasser 2006). The vertical structure dimension is based on the work of (Hitchins, 2000) who proposed the five-layer model for systems engineering. The horizontal LCP dimension is based on the work of (Kasser and Massie, 2001). The third risks dimension is an extension of the work of (Shenhar and Bonen, 1997) which defined and four levels of technological uncertainty (risk). Each dimension of the map is detailed bellow.the map divides the systems world into cells of shared attributes and similarities, i.e. cells of a tool box of processes and methodologies relevant to the SE present activities. It is the basis of a sequential navigation process (Bonen, Bustnay 2008, lec.13), which will guide the SE, from project description to the selection of the tool box suitable to his present activities Structure The main systems layers were presented in Table 1 (Sec.3.2.1). The discussion here is limited to single systems (Layers 1, 2 in the table) which include: 1. An Inanimate System activated and often also controlled, by an external human operator. 2. A System of Systems ( SoS), which integrates various inanimate systems and humans together, to produce or operate A SoS. Integration is performed by public and private networks. The SoS configuration may be fixed or flexible; that is with the capability to replace, add or delete modules and links (Sec. 3.1) Life Cycle Phases The phases of the inanimate systems life cycle defined as: A. Identifying the need. B. Requirements analysis. C. Design of the system. D. Construction of the system. 51

54 קול המערכות - כתב העת של מהנדסי המערכות בישראל E. Testing of the system components. F. Integration and testing of the system. G. Operations, maintenance and upgrading the system. H. Disposal of the system. The main two stages of the life cycle of a SoS were described in sec It usually begins with the formation stage of the system, i.e. the creation and initial implementation stage of the new system Later the system evolves gradually over many decades until its downfall The whole life cycle is summarized in Fig Systems Risks Levels Systems Evolution Risks were discussed in detail in Sec.3.6. Here they are summarized and applied to the mapping and navigation process. Technological Risks in inanimate sub-systems/systems development. SoS Formation Stage Development Risks. Existing SoS Incremental Evolution Risks (Presently perceived and future long term unperceivable risks). Metamorphosis of Existing SoS Risks Inanimate System Navigation Inanimate system navigation includes: Identification of Industry and Missions. Identification of the present and next LCP. Identification of sub-system risk levels. Identification of system risk levels. Selection of relevant activities and tools SoS Navigation SoS Navigation includes: Identification of present stage (Formation or incremental) and location within the stage. Selection of activities relevant to the formation stage Initial architecture design. Risk Analysis: Initial, present location and long term. Selection of relevant activities and tools. Selection of activities, including risks, relevant to the long incremental stage (Sec.5.5). Identification of the need for radical change requiring metamorphosis. Design of the metamorphosis process, including paths circumventing inertia. 52

55 8. Areas for Future Research Some areas for future research are pointed out here: Sage (March 2006) suggested three primary areas: 1. SoS Structures including associated issues of adaptation, evolution and emergence. 2. Transdiciplinarity elaboration including processes required for knowledge management and fusion of various system perspectives. 3. Evolution of better and trustworthy methods and tools for system engineering. Other areas include: 4. The inclusion of humans in SoS necessitates Better methodologies and tools for the design of SoS architecture. In particular, where to insert humans in the SoS and in what roles. 5. Elucidation of SoS incremental stage activities and processes including metamorphosis issues. 6. Limits to complexity of MMS. Emergence often leads to more complex systems. In particular, in the course of the evolution of complex adaptable SoS which include humans, system complexity can increase a great deal. Also, present day communication technologies enable design and construction of very complex systems. Such systems may deal better with and adapt rapidly to changing complex environments. But, in some cases, they will breakdown into stable sub-systems or even collapse completely. Hence, their main design issue is how to make the best of complexity, I.E. balancing performance vs. robustness. The many cases of collapse of very complex systems suggest that there are limits to complexity. At present, there is apparently no systematic methodology for delineating the complexity limits under various conditions. 7. Systems and networks. The processes of co-evolution and interaction of systems and networks should be explored. In particular, do they lead to more complex systems and in what direction. 8. Unresolved or irresolvable issues. Some problems await resolution, but it is important to locate irresolvable issues. 9. Future Theory Evolution Paths The theory should be evolvable. What are the limits of the present theory? What are the pressing directions of evolution? They may be different from those mentioned above. 9. Conclusions Systems engineering requires a base of relevant and applicable systems theory covering the creation of a new systems and their further evolution. Such a theory of MMS, should oriented towards the needs of the (SE). System structures include inanimate systems, and SoS, which contain humans. This paper focuses on SoS., which, by definition, have some important specific features: The inclusion of humans (Sec.3.4) in SoS requires 53

56 קול המערכות - כתב העת של מהנדסי המערכות בישראל addition of new methodologies and tools for architecture design; SoS evolve over a long period, which often includes many generations of inanimate systems and people; hence it is necessary to deal with their long term evolution issues; SoS are dispersed, hence they must use connecting networks to tie their parts together. Thus a system and its networks are complementary. They interact and often co-evolve. An adaptive system cannot exist without adaptive networks which form the necessary adaptation links. Men made system theory laws include laws of nature and man made laws. The latter, if they interfere with the laws of nature, are hazardous. Theory implementation requires a great deal of further work. 10. References Z.Bonen, On System Development Planning, presented in Israel Conference on Operations Research 1969, published in Development in Operations Research (Book), Gordon & Breach 1971, pp Z.Bonen, Evolution of Military SoS, (in Hebrew), Rafael report Z. Bonen, Network Centric Warfare, RAFAEL Ltd., summer 2006, restricted Z. Bonen, T. Bustnay, Issues in Man Made Systems Theory ME Course Lecture Notes, (in Hebrew), Technion, summer 2008 S.C. Cook, J.E. Kasser, T.K.J. Ferris, Elements of a Framework for the Engineering of Complex Systems, 9th ANZSYS Conference, November S.N. Dorogovtsev, J.F.F. Mendes, Evolution of Networks (Book), Oxford university Press D.K. Hitchins, World Class Systems Engineering the five layer model, co.uk, 2003 Kasser, J.E. and Massie A., A Framework for a Systems Engineering Body of Knowledge, Proceedings of the 11th Annual International Symposium of the International Council on Systems Engineering (INCOSE), Melbourne, Australia, 1-5 July 2001, Paper No J.E. Kasser, Introducing the Role of Process Architecting, University of South Australia J.E. Kasser, The Hitchins-Kasser-Massie (HKM) Framework for Systems Engineering (2006 submitted). S. Johnson, Emergence, (book), Scribner 2001), Manchester pp ISO/IEC International Standard 15288, 2002.? H. McManus, D.Hastings, A Framework for Understanding Uncertainty and Its Mitigation and Exploitation in Complex Systems,IEEE Engineering Majagement Review, Third Quarter Adm. W.A. Owens, The Emerging System of Systems, U.S. Naval Institute Proceedings, May 1995, pp A.P.Sage, The Intellectual Basis for and Content of Systems Engineering, Incose Insight, March 2006, pp A.P.Sage, The Evolution and Future of the Profession of Systems Engineering and Management, , p.11. A. J. Shenhar and Z. Bonen, The New Taxonomy of Systems: Toward an Adaptive Systems Engineering Framework, IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, (1997), H.A. Simon, The Sciences of The Artificial, Chap.4, M.I.T. Press

57 חידושים ואתגרים בהנדסת מערכות נכללו במסגרת האירועים העיקריים בתקופה ינואר מאי 2011 ד ר אביגדור זוננשיין מהנדס מערכות ותהליכים, רפאל בכתבה זו נסקר שני אירועים מרכזיים בתחום הנדסת המערכות שהתקיימו בארץ בחודשים האחרונים: יום העיון ה 12 להנדסת מערכות על שם ד ר יוסי לוין שהתקיים בטכניון ב 24 לינואר 2011 והכינוס הבינלאומי השישי להנדסת מערכות של האיגוד הישראלי להנדסת מערכות INCOSE_IL שהתקיים ב 8-9 למרץ 2011 במלון דניאל, הרצלייה. תכן מערכות חסינות )RESILIENT( ותכן מערכות חסונות )ROBUST( הודגמו ביום העיון ה- 12 להנדסת מערכות ע ש יוסי לוין ב 24 לינואר 2011 קיימנו יום העיון ה 12 להנדסת מערכות ע ש ד ר יוסי לוין ז ל. גם הפעם התקיים היום בטכניון בחסות וארגון מרכז גורדון להנדסת מערכות. ביום העיון השתתפו כ 200 איש מהתעשייה וממערכות הביטחון עם נוכחות גבוהה של אנשי רפאל ותע א השותפים למסורת ימי עיון אלו. את יום העיון פתחו בברכות פרופ אביב רוזן, ראש מרכז גורדון להנדסת מערכות בטכניון, מר חזי גריסים, סמנכ ל התע א לפרויקטים מיוחדים וד ר נפתלי סלע, מדען ראשי של רפאל אשר ברכו על המשך המסורת של ימי העיון ע ש יוסי לוין והדגישו את החשיבות של הנדסת מערכות חזקה להצלחת הפרויקטים והתעשייה. מר אסף לוין, בנו של יוסי, הציג מצגת מרתקת על תולדות חייו של יוסי והודה לכל השותפים בהמשך המסורת של ימי עיון לזכר יוסי. מסורת נוספת שהמשכנו בה היא חלוקת פרסי מהנדס מערכות מצטיין ע ש יוסי לוין. הזוכה בשנה זו מטעם התע א היא יהודית מעוז לפיד מחטיבת מב ת. המצטיין מטעם רפאל הוא דוד פרג מחטיבת הטילים ולוחמת רשת. יום עיון זה הוקדש הפעם לשתי תכונות מערכתיות חיוניות- חסינות.)ROBUST( מערכתית וחוסן מערכתי )RESILIENCE( חסינות )RESILIENT( מוגדרת כיכולת של מערכת לעמוד באימפקט חיצוני חריף ולחזור לתפקד תוך זמן קצר יחסית. האימפקט החיצוני יכול להיות זדוני )כמו פעולת טרור, וירוס או תולעת ברשת, פעילות מלחמתית(, או תוצאה של תופעת טבע )כמו רעידת אדמה, שיטפון, צונאמי..( או תוצאה של תאונה חמורה. חוסן )ROBUSTNESS( של מערכת מוגדר כיכולת שלה לבצע את משימתה בהצלחה בטווח רחב מסביב לנקודת העבודה האופיינית. 55

58 קול המערכות - כתב העת של מהנדסי המערכות בישראל את יום העיון פתחה הרצאתו של JACK RING באמצעות ה SKYPE מאריזונה. טכנולוגיית הסקייפ התגלתה כלא רובוסטית ונאלצנו לקטוע את ההרצאה לקראת סיומה עקב קשיי קליטה. בפתיחת הרצאתו הציג ג ק רינג סדרה של דוגמאות למערכות חסינות כמו - העצים שמתאימים את עצמם לרוח, שדירת מכוניות במרוץ מכוניות, מטוס שמצליחים להחליף לו גלגל נחיתה באוויר. בהמשך, ג ק הציג מודל כללי לתיאור ההתנהגות של מערכת חסינה: Resilient System Meta-model GS System INPUTS Request Resources Time A Goal Action Triggers Energy Competency Situation Closure, G-S OUTPUTS Response Status Reports Learning Disturbances Culture Business Climate Competing Goals Situation Measures Goal Attainment Sensitivity to Disturbance Stability Limits 1/24/11 16 Jack Ring. Attributed copies permitted מיכאל ארוב משטח סמל א, רפאל הציג היבטים של החסינות של ה CYBER תוך השוואתו להיבטי אבטחת מידע. פרופ גריגורי לויטין מחברת החשמל הציג סדרת מודלים לאופטימיזציה של החסינות של מערכות באמצעות מערכות הגנה והבטחה ובאמצעות פיזור גיאוגרפי. ד ר שרה ביתן הציגה גישה של מדדי הבטחה ל מעטפת התקפה שתשפר את החסינות של מערכות. פרופ דן זכאי מהמרכז הבינתחומי בהרצלייה, הציג גישות לפיתוח החסינות האנושית תוך הצגת דוגמאות לניסויים שביצע בתחום זה. ד ר קובי ריינר, מחטיבת הטילים הציג והדגים יישומי סימולציות ספרתיות כשיטה וכלי לאימות התכן. מר צבי לנדו ממטה התע א וניר משקיף ממעבדות המחקר של IBM תיארו יחד סביבת כלים ותהליכים משולבת לפיתוח מערכות. גב יעל קלדור מרפאל, הציגה תהליך תכן רובוסטי מבוסס על אופטימיזציה רב ממדית. האופטימיזציה 56

59 מבוססת על כלי.Mode Frontier באופטימיזציה זו משיגים נקודת עבודה רובוסטית יותר תוך התחשבות בכל הפרמטרים )פנימיים וחיצוניים( המשפיעים על התכן המערכתי. מר אלי לוזון מרפאל, המשמש כיום כממונה על שש סיגמה במטה האיכות בהנהלת רפאל, תיאר את עקרונות השיפור המבוסס על יישום שיטת שש סיגמה. אלי הדגים את העקרונות על דוגמאות אמיתיות וסיכם בלקחי 6 השנים האחרונות של יישום והטמעת תהליכי שש סיגמה ברפאל. ההרצאה האחרונה ביום העיון ניתנה ע י ד ר אורי נפתלי ממפעל מב ת של התע א. בהרצאה זו תיאר את משימת הצבת לווין עם מצלמה מכמ ית במסלול סביב וונוס לצורך צילום ומיפוי כוכב מיוחד זה. מהמשוב שקיבלנו ממשתתפי יום העיון - היה זה יום מוצלח, מעניין ובעל תרומה לקידום הידע והתובנות של מהנדסי המערכות במפעלים בכלל, וברפאל ובתע א בפרט. להערכתנו, תכן מערכות חסינות וחסונות הוא לחם חוקנו, ולכן לימוד ודיון בנושא מקדם אותנו בכוונים חשובים לנו ובמגמות חיוניות למהנדסי המערכות בתעשייה ובצבא בישראל. הרצאה ביום העיון 57

60 קול המערכות - כתב העת של מהנדסי המערכות בישראל הנדסת מערכות עולה מדרגה בכינוס הבינלאומי השישי להנדסת מערכות של האיגוד הישראלי להנדסת מערכות - הכינוס הבינלאומי השישי - גדול יותר ועשיר יותר הכינוס הבינלאומי השישי להנדסת מערכות של האיגוד הישראלי להנדסת מערכות INCOSE_IL התקיים ב 8-9 למרץ 2011 במלון דניאל, הרצלייה. בכנס השתתפו מספר שיא של 500 מהנדסי מערכות, מנהלי פרויקטים לפיתוח מערכות ומהנדסי תכן העובדים בכ - 50 חברות בישראל ובעולם. במסגרת הכינוס התקיימו 15 מושבים מקצועיים בהם הוצגו למעלה מ 50 עבודות בתחומים שונים של הנדסת מערכות, כמו: חידושים בניהול סיכונים, שילוב אפקטיבי של הנדסת תוכנה והנדסת מערכות, ממצאי מחקרים בהנדסת מערכות, חשיבה מערכתית ומידול מערכתי, תהליכים והצלחות בבחינות וניסויים, שילוב הנדסת אנוש בהנדסת מערכות, הנדסת מערכת מבוססת מודלים וסימולציות,MBSE תהליכים ואתגרים באינטגרציה. במושבים אלו הוצגו למעלה מ 50 עבודות ומאמרים. פנל הפתיחה החגיגית של הכינוס בהשתתפות )מימין לשמאל(: ד ר אביגדור זוננשיין יו ר הכינוס, ג ון תומאס הנשיא הנבחר של,INCOSE רן טוטנאור יו ר התאחדות התעשיינים, חיים רייכמן נשיא,INCOSE_IL משה סלם מנכ ל אילטם ביום השני של הכינוס התקיימו ארבעה סמינרים על חשיבה מערכתית לפתרונות חדשניים )ע י פרופ ג ו קסר(, תכנון מוקדם לאינטגרציה, תכנון מאמצי הנדסת המערכות )ע י אריק הונור(, הנדסת מערכות פרואקטיבית לפרויקטים מצליחים )ע י נילס מלוטאו(. הכנס אפשר למשתתפים להיפגש עם מומחים ו בעלי קבלות בהנדסת מערכות מהעולם ומהארץ. בכנס התקיימה תערוכה מקצועית עשירה בה נפגשו משתתפי הכנס עם כ- 15 ספקי כלים להנדסת מערכות. חלק מספקי הכלים הציגו את הכלים במושב האתגר לספקי הכלים TOOL VENDORS.CHALLENGE המוטיב המוביל של הכינוס היה: סוף מעשה במחשבה תחילה LOOK BEFORE YOU LEAP 58

61 אנחנו הדגשנו את אלמנט התכנון מראש ולטווח ארוך של מאמצי הנדסת המערכות, וההשקעה הראשונית החיונית בגיבוש קונספט אופטימאלי וארכיטקטורת המערכת העונה לצרכים. מושב פתיחה בחסות שר המדע והטכנולוגיה מושב הפתיחה של הכינוס כלל דברים של פרופ דניאל הרשקוביץ, שר המדע והטכנולוגיה, אשר כהרגלו נתן מבט על הנדסת מערכות על פי המקורות. האדם נברא עם ראיה מערכתית של 360, אבל כאשר נלקחה ממנו הצלע לבריאת חוה, למעשה נלקח ממנו צד הראיה מאחור, והאישה אמורה להשלים פער זה; מר אבי חסון, המדען הראשי, משרד התמ ת, הדגיש בדבריו את חשיבות החשיבה המערכתית להשגת חדשנות ומצוינות טכנולוגית בתעשיית ההי-טק ובתעשייה המסורתית; מר ג ון תומאס, הנשיא הנבחר של,INCOSE דיבר על אתגרי הנדסת המערכות בעידן הגלובאלי; מר ברני גורדון )באמצעות וידאו(, מייסד מרכז גורדון בטכניון, הציג את תפקיד מהנדסי המערכות במנהיגות ההנדסית; גב יעל גרמן, ראש עיריית הרצלייה, בירכה את באי הכינוס שנערך בהרצלייה ביום האישה הבינלאומי והציגה ציפייה ליותר מהנדסות מערכות; מר רן טוטנאור, יו ר ענף המתכת, השירותים והתשתיות בהתאחדות התעשיינים הציג את אתגרי מערכת החינוך בתחומים הטכניים והטכנולוגיים; מר חיים רייכמן, נשיא INCOSE_IL ומשה סלם מנכ ל אילטם ברכו את באי הכינוס והוקירו את כל אלה שתרמו להצלחת הכינוס. שר המדע, פרופ דניאל הרשקוביץ, מברך את באי הכינוס ומספר על יישום הנדסת מערכות במקורות כבוד והדר לתורמים לקידום הנדסת מערכות בישראל בסיומו של מושב הפתיחה חולקו תעודות חבר כבוד באיגוד הישראלי להנדסת מערכות למר חיים רוסו, סמנכ ל לטכנולוגיה ומצוינות אלביט מערכות, מר יעקב גולדמן, סמנכ ל תפעול תע א, ד ר אבי גינזבורג, סמנכ ל למו פ לשעבר רפאל, מר אילן פלד, מנהל תכנית מגנ ט, מר ברני גורדון, מייסד מרכז גורדון בטכניון )את התעודה בשם ברני קיבל מר עמוס חורב נשיא הטכניון לשעבר(, מר משה סלם, מנכ ל אילטם. תעודות עמית באיגוד קיבלו: מר עוזי אוריון, אלביט מערכות אלקטרואופטיקה אל אופ, ד ר עמיהוד הרי, הטכניון, פרופ מנחם וייס, הטכניון. התעודות חולקו על התרומה המתמשכת של מקבליהם בקידום הנדסת מערכות בישראל. כפי שנאמר בטקס אתם מקבלים את ההערכה לא רק על מה שעשיתם למען הנדסת המערכות אלא גם על מה שתעשו בעתיד לקידום תחום זה. 59

62 קול המערכות - כתב העת של מהנדסי המערכות בישראל מכל המאמרים שהוגשו לכינוס נבחר המאמר המצטיין בנושא ניהול סיכונים בגישה הדטרמינסטית שנכתב והוצג ע י שמעון זיירמן מרפאל. תודות לחברות והגופים שהעניקו חסות לכינוס: רפאל, אלביט מערכות, HP אינדיגו, מרכז גורדון בטכניון, המכללות בעלות מסלול הכשרה למהנדסי מערכות: אורט בראודה, מכללת אפקה, מכון טכנולוגי חולון IEEE COMPUTER וכן, לשכת המהנדסים והאדריכלים, איגוד תעשיות האלקטרוניקה והתוכנה,.HIT.SOCIETY הנדסת מערכות כמנהיגה את ההנדסות הפנל המסכם של תכנית היום הראשון של הכינוס דן בשאלה המסקרנת: האם הנדסת המערכות יכולה להוות מנהיגות הנדסית?. השתתפו בפנל: ג ון תומאס, הנשיא הנבחר של,INCOSE מר חיים רוסו, סמנכ ל לטכנולוגיה ומצוינות אלביט מערכות מר שם - טוב )טובי( בכר, מנכ ל מדור כימיקליים, פרופ אביב רוזן, ראש מרכז גורדון בטכניון, פרופ יוחנן ארזי, נשיא מכללת אורט בראודה, פרופ מרדכי סוקולוב, נשיא מכללת אפקה, מר דב אוסטר, מהנדס ראשי מל מ/תע א. כל דוברי הפנל הדגישו את חשיבות המנהיגות ההנדסית של מהנדסי המערכות ושיש לכלול את היבטי המנהיגות בהכשרה ובפיתוח של מהנדסי המערכות באקדמיה ובמפעלים. הודגש שהמנהיגות של מהנדסי המערכות מתבטאת לפחות בהיבטים הבאים: תקשורת בלתי אמצעית עם הלקוחות, המשתמשים והשוק, בקביעת הסטנדרטים של עבודת ההנדסה, וביצירת דור המשך למהנדסי המערכות. הסמכה בינלאומית של מהנדסי מערכות )CSEP( - האתגר הבא לראשונה בישראל נחשפו משתתפי הכינוס לפוטנציאל של תכנית ההסמכה הבינלאומית למהנדסי מערכות.CSEP במסגרת הכינוס נערך מפגש בין דיויד וולדן המרכז את נושא ההסמכה ב INCOSE ונציגי מפעלים בישראל. סוכם שנשאף למהלך פילוט להכשרת והסמכת מספר מהנדסי מערכות בישראל. את המהלך יוביל דר עמיר תומר. הרצאה לזכרו של ד ר זאב בונן ז ל לצערנו הרב, בשנה האחרונה נפטר ד ר זאב בונן, אשר עד יומו האחרון פיתח גישות חדשות להנדסת מערכות. זאב ז ל הוא חבר כבוד של.INCOSE_IL ביוזמת ובהנחיית ד ר אבי גינצבורג מתקיים במרכז גורדון בטכניון קורס מערכות מעשה ידי אדם שמבוסס על רעיונות של זאב ז ל. עבודת הסטודנטים המצטיינת בקורס זכתה בהערכה ו 5000 תרומת מרכז גורדון. העבודה הוצגה במושב בכינוס. גדי ואורי בונן, בניו של זאב, אמרו דברים לזכרו. לא ינום ולא יישן הנוהג בישראל במסגרת ההכנות לכינוס הכרזנו וקיימנו תחרות אתגר שמטרתה להוכיח ידע, הבנה ויכולת יישום של תהליכי הנדסת מערכות תוך מתן מענה לצורך אמיתי. התחרות השנה עסקה במערכת למניעת הירדמות בנהיגה. בתחרות זכה צוות של סטודנטים מהפקולטה לתעשייה וניהול בטכניון שעבד בהנחיית פרופ דב דורי. הקבוצה זכתה בפרס בסך 4000 שאילטם ו- INCOSE_IL מעניקים לעידוד ההשתתפות בתחרות אתגר. יש לציין שחברי הקבוצה הזוכה תרמו את סכום הכסף לעמותת אור ירוק למלחמה בתאונות בדרכים. 60

63 העבודה הוצגה ע י הסטודנטים במושב הנדסת מערכות שייכת לצעירים, בו הוצגו עוד עבודות של סטודנטים באוניברסיטאות שונות. זו גם ההזדמנות לברך את פרופ דב דורי, על קבלת תואר FELLOW מטעם INCOSE לשנת אנו שמחים על בחירה זו, ואני שמח שהוא הצטרף אלי במשפחת ה.FELLOWS הפרס בסך 4000 מוענק לצוות הסטודנטים בהנחיית פרופ דב דורי, על מענה לאתגר למניעת ההירדמות בנהיגה - לא ינום ולא יישם הנוהג בישראל היום השלישי למען האורחים לאורחינו מחו ל ארגנו ביום חמישי ה 10 למרץ, כחלק מהכינוס, סיור מקצועי במעבדות אינטל קריית גת, במעבדות אוניברסיטת בן גוריון, ובמוזיאון ח א בחצרים. הסיור היה מרשים ומלמד. נראה שעל בסיס התרשמותנו מהעשייה המערכתית באוניברסיטת בן גוריון, בפקולטה לתעשייה וניהול ובמעבדות דויטשה טלקום, נכון יהיה ליצור איתם שיתוף פעולה מקצועי. היום השלישי, סיור במוזיאון חיל אוויר 61

64 קול המערכות - כתב העת של מהנדסי המערכות בישראל I LOVE INCOSE במהלך הכינוס התפרצה לריסה המנקה למספר מושבים והביעה דעתה על הערך המוסף של הנדסת מערכות לעבודתה כמנקה ולחיי הזוגיות שלה. במושב הפתיחה היא הפתיעה את ג ון תומאס והעניקה לו כרית צבעונית ורקומה.I LOVE INCOSE לריסה וג ון מרימים כוס אקונומיקה להצלחת INCOSE והכינוס סיכום - היה טוב וטוב שהיה למהנדסי מערכות צעירים וותיקים - הכנס הזה היה הזדמנות מיוחדת ומצוינת ללמידה מניסיון אחרים בעיסוק ובמקצוע של הנדסת מערכות. קיבלנו משוב בע פ חיובי מאד ומפרגן. טפסי המשוב בשלבי ניתוח, ומהם נפיק לקחים מסודרים לקראת הכנסים הבאים. תודות לצוות אילטם ובראשם משה סלם וחגית קורן. תודות לחברי הוועדה המארגנת שסייעו בגיוס המאמרים, בבדיקת וטיוב המצגות ובניהול המושבים. תודות לפרופ אביב רוזן על התמיכה המיוחדת של מרכז גורדון בכינוס. תודות למרצים שהסכימו לשתף את באי הכינוס בניסיון, ידע ומידע. רוב תודות לאורחים מחו ל אשר תרמו לבינלאומיות של האירוע. 62